Best for
- Teams operating several production AI workflows
- Organizations granting connectors or automations write access
- Marketing systems teams experiencing silent failures or duplicate actions
Create an observability and incident layer for production GTM agents, automations, connectors, and AI-assisted systems across execution health, output quality, cost, credentials, retries, dead letters, and recovery.
A production workflow registry, execution and quality telemetry, reliability dashboard, failure runbooks, deduplicated alerts, incident recovery, cost monitoring, and lifecycle decisions.
Quick view
Check the audience, core tools, and access before you start the detailed steps.
Best for
Core tools
4 tools used across the workflow.
Access
Preview the open steps, then unlock the remaining implementation details and prompts.
Why this works
Production AI workflows can complete technically while producing malformed, unsupported, duplicated, or expensive outcomes. This workflow monitors execution, semantic quality, cost, credentials, and destination state under version-aware SLAs. Failure classes determine retries and dead-letter behavior, while manual fallbacks and reviewed recovery keep operational authority with humans.
Expected results
Incident detection
Failures visible within the defined SLA
Shared error workflows, execution logging, validation, and severity rules surface failures that otherwise remain silent.
Duplicate prevention
Business-action idempotency enforced
State-changing workflows check business keys before writes and track parallel or replayed executions.
Quality visibility
Technical and semantic success separated
Schema checks, evidence rubrics, gold sets, and human calibration expose fluent but unusable outputs.
Cost control
Cost per useful output tracked
Model usage, connector operations, retries, human correction, and rework are visible by workflow version.
Step-by-step workflow
The first 2 steps are open. Pro unlocks the remaining steps, copy-paste prompts, pro tips, tool-by-tool setup guidance, and implementation details.
2-4 hours
2-4 hours
Create a registry containing workflow ID, name, business owner, technical owner, purpose, users, trigger, schedule, systems, credentials, model, version, inputs, outputs, write actions, approval gates, SLA, manual fallback, and retirement date. Include n8n, connector, scripted, and human-in-the-loop workflows. Mark experimental systems separately from production. Do not monitor an unnamed workflow with no accountable owner. Record the operation against stable identifiers such as workflow_id, version, run_id, triggered_at, completed_at, preserve the raw source reference and capture time, and write any transformation or decision into the system’s change history rather than replacing the prior value. Use an explicit pass, warning, or hold disposition, attach the supporting evidence IDs, and assign every unresolved exception to an owner and due date before moving to the next step. Give the AI concrete source material, required fields, and a review checklist so the output can be judged by a human operator.
A complete production workflow registry with owners and criticality.
The registry should include systems that only read or draft. Confidentiality, cost, and wrong-answer risk exist even without automated writes.
1-2 hours
1-2 hours
For each workflow, define service-level indicators for run success, latency, duplicate rate, stale input, schema validity, approval completion, destination verification, output quality, manual intervention, cost, and incident count. Set targets and error budgets by criticality. Distinguish technical success from business-output success. Record the evidence source and evaluation window for every indicator. Create a dedicated Claude Project named `gtm-ai-workflow-reliability-failure-monitor-ops` with `instructions.md`, `field-dictionary.json`, `source-register.csv`, `review-rubric.md`, `approved-examples.md`, and `changelog.md`; assign a named owner and use `vYYYY.MM` releases. Refresh the named source exports on the workflow cadence, archive superseded inputs by source ID and date, and review instructions, examples, permissions, and maintenance needs quarterly. Run this template in the workflow’s persistent Claude Project after attaching or linking the approved source records named for this step. Write down the decision criteria, owner, required inputs, and what is deliberately out of scope so the rest of the workflow does not drift.
Workflow-specific reliability, quality, and cost indicators with targets.
Pro workflow preview
Previewing 2 of 14 steps
Get the remaining 12 steps, copy-paste prompts, pro tips, tool-by-tool setup guidance, and ongoing workflow and prompt releases.
$9/month
ROLE
You are the governed analysis and operations assistant supporting the marketing systems engineer and workflow owner. You are working inside the GTM AI workflow reliability and failure monitor, where traceability, stable identifiers, and human authority matter more than producing a polished but unsupported answer.
OBJECTIVE
Complete workflow step 2, “Define reliability, quality, and cost SLIs,” and produce this operational outcome: Workflow-specific reliability, quality, and cost indicators with targets. The result must be immediately usable by the named operator without inventing records, silently changing approved state, or obscuring uncertainty.
INPUTS
1. SOURCE RECORDS: {{define_reliability_quality_and_cost_slis_source_records}}
2. FIELD DICTIONARY AND ALLOWED VALUES: {{define_reliability_quality_and_cost_slis_field_dictionary}}
3. OPERATING, PERMISSION, AND DECISION RULES: {{define_reliability_quality_and_cost_slis_operating_rules}}
4. APPROVAL CONTEXT, OWNERS, AND DEADLINES: {{define_reliability_quality_and_cost_slis_approval_context}}
5. PRIOR VERSION, SNAPSHOT, OR CURRENT STATE: {{define_reliability_quality_and_cost_slis_prior_version_or_state}}
Authoritative evidence may include n8n execution logs, Airtable workflow registry, validation results, sampled outputs, cost records, alerts, and incident reviews.
WORK TO PERFORM
1. Execute the specific job described by “Define reliability, quality, and cost SLIs”; do not broaden the task into a generic strategy exercise.
2. Use the canonical field names and IDs supplied in the inputs, especially workflow_id, version, run_id, triggered_at, completed_at, status.
3. Separate observed facts, operator-entered decisions, calculations, and model inferences so reviewers can trace how each conclusion was produced.
4. Return records that can be copied into the GTM AI workflow reliability and failure monitor without renaming identifiers or collapsing one-to-many relationships.
5. Follow the approved operating rule for this step and make the next action, owner, review gate, and exception state explicit.
6. Identify duplicates, conflicts, stale records, missing IDs, permission problems, and records that must be held for human resolution.
7. Produce a compact review summary explaining what changed, what did not change, what remains uncertain, and what the operator should do next.
OUTPUT SCHEMA
Return valid JSON only, using this exact top-level structure:
{
"workflow_slug": "gtm-ai-workflow-reliability-failure-monitor",
"step_number": 2,
"step_title": "Define reliability, quality, and cost SLIs",
"run_status": "pass|warning|hold|fail",
"source_records": [
{"source_id": "string", "source_type": "string", "captured_at": "ISO-8601|null", "authoritative": true, "notes": "string|null"}
],
"records": [
{"workflow_id": "value|null", "version": "value|null", "run_id": "value|null", "triggered_at": "value|null", "completed_at": "value|null", "status": "value|null", "error_class": "value|null", "evidence_source_ids": ["string"], "confidence": "high|medium|low", "review_status": "approved|needs-review|held"}
],
"exceptions": [
{"record_id": "string|null", "exception_type": "string", "severity": "low|medium|high|critical", "evidence": "string", "owner": "string", "required_action": "string"}
],
"changes_from_prior_state": [
{"record_id": "string", "field": "string", "prior_value": "value|null", "proposed_value": "value|null", "reason": "string", "source_ids": ["string"]}
],
"review_summary": {"facts": ["string"], "inferences": ["string"], "open_questions": ["string"], "next_actions": [{"action": "string", "owner": "string", "due_date": "YYYY-MM-DD|null"}]},
"qa": {"schema_valid": true, "ids_preserved": true, "evidence_complete": true, "human_approval_required": true}
}
GUARDRAILS
- Treat the supplied field dictionary, permissions, approval matrix, and prior approved state as binding.
- Do not create facts, sources, IDs, dates, metrics, quotes, customer permissions, or approvals that are not present in the inputs.
- Do not perform, simulate, or claim an external write; return proposed records or actions for the governed workflow to apply.
- Do not collapse conflicting evidence into a single confident statement. Preserve the conflict and identify the required owner.
- pause or degrade safely when failure rate, duplicate actions, malformed output, credential errors, cost, or semantic quality exceed the approved threshold.
EVIDENCE REQUIREMENTS
Every material claim, classification, score, recommendation, mutation, or exception must reference one or more supplied source IDs. Keep raw evidence distinct from derived analysis, retain capture dates when provided, and mark evidence as stale when it falls outside the approved refresh window. A record without adequate evidence must be returned with review_status “held,” not completed through guesswork.
UNCERTAINTY HANDLING
Use high confidence only when authoritative sources agree and the required identifiers are present. Use medium confidence when the evidence is credible but incomplete or indirect. Use low confidence when evidence is sparse, stale, inferred, or contradictory, and state the exact missing information that would change the result. When uncertainty could trigger an external action, financial commitment, customer communication, publication, suppression, or system mutation, return run_status “hold.”
HUMAN REVIEW
The marketing systems engineer and workflow owner must review the JSON before any state change or external action. The approval gate is: the workflow owner approves SLOs and lifecycle decisions while the systems engineer validates retries, idempotency, dead-letter handling, and recovery. The reviewer must verify source IDs, field mappings, permission scope, exception handling, and the proposed next action; record the reviewer, timestamp, disposition, and any edits in the workflow’s mutation or decision log.Related workflows
Continue with workflows that share a similar GTM motion, category, or tool stack.
A governed paid-media change ledger and experiment memory with snapshots, hypotheses, approvals, execution evidence, rollback rules, result classification, and reusable learnings.
A stateful account decision system with signal provenance, deterministic exclusions, ranked eligible actions, approvals, safe execution, outcomes, and policy audits.
A stateful event outreach agent with Gmail and Calendar IDs, reply classes, suppressions, reviewed drafts, verified meetings, exception SLAs, audit logs, and a clean shutdown process.