Skip to main content
A production runbook gives you the ordered first moves for failed, runaway, or unsafe Attio workflow behavior in production. Each section starts with a symptom you see in the Runs tab, which is the log of every time a workflow ran. From there it gives you a sequence you can run under pressure. A weekly review keeps small problems from becoming incidents. Reach for this page when a live workflow is failing, writing the wrong data, or burning credits faster than you expected. One rule holds across every scenario. A workflow that is writing data or spending credits the wrong way is an active incident, so stop the damage before you diagnose it. Disabling a workflow is reversible. A thousand bad writes are not.
Before you investigate a runaway or a bad-data write, disable the workflow first. Disabling stops new runs. Runs already in progress finish on the version they started on. This buys you time to read the evidence without the problem getting worse.

​
Triaging a failed run

A failed run shows a red block in the run viewer. But the red block is rarely where the bug actually starts. Trace upstream from the failure to the first wrong value. Fix the draft. Then confirm with a fresh run rather than a retry.
1

Open the workflow's Runs tab

Go to the workflow and open the Runs tab. The list shows every execution with its status, runtime, and credits consumed.
2

Select the newest failed run

Pick the most recent run with a failed status. The canvas becomes a frozen snapshot of that one execution. Green arrows show the path it took, and a red marker shows the failure point.
3

Read the failed block's inputs, outputs, and error

Click the red block. The sidebar shows its Inputs (what it received), its Outputs (what it produced), and the error detail. Read all three before forming a theory.
4

Trace upstream to the first wrong value

First ask one question: is the input wrong, or is the block misconfigured? If an input looks wrong, open the upstream block that produced it and inspect its Outputs. Repeat until what you expected and what you got first differ. That block is the bug, no matter where the red marker sits.
5

Fix the draft and publish

Correct the misconfigured block in the draft, then click Publish changes. Edits to a live workflow do not apply until you publish.
6

Trigger a fresh test run

Trigger a new run to confirm the fix. A retry replays the version that was published when the original run triggered, not your fixed version. Only a fresh run proves the repair.
You will hit a few named failures most often: an empty variable, a list-entry mismatch, and a failed formula. Match the message against common errors.

​
Stopping runaway volume

Runaway volume is a workflow firing far more often than its business event should justify. Usually the trigger is unscoped, or the workflow re-triggers itself. Disable it the moment it is writing or spending. Then scope and guard it before you turn it back on.
1

Disable the workflow

If the workflow is writing data or spending credits, disable it now. New runs stop immediately. Runs already in flight finish on their original version.
2

Check whether the trigger is unscoped

Open the trigger. A Record updated trigger watching every attribute on an object fires on every edit. That includes edits the workflow itself makes. Scope it to the single attribute that should start the run.
3

Add an early Filter

Place a Filter block immediately after the trigger. A Filter stops a run that should not continue. Put it early so those runs stop before any write or AI block spends credits.
4

Add a self-trigger guard where the workflow writes back

Sometimes a workflow writes to the same object it triggers on. In that case, add the condition Updated by is not Workflow to the early Filter. This stops the workflow from re-triggering on its own writes. That self-triggering is the most common cause of an infinite loop.
5

Re-enable only after a one-record test

Trigger the published workflow against a single record. Confirm in the Runs tab that it fires once and stops. Re-enable only after that test passes.

​
Reversing a bad data write

A bad data write is a workflow that ran successfully but wrote the wrong value to live records. The run is not red, so you find these by the data, not by the error. Disable the workflow, scope the damage, and correct it. Then add an idempotency guard so a republish cannot repeat the mistake. An idempotency guard is a check that makes running the same workflow twice safe. The second run does not duplicate what the first run already did.
1

Disable the workflow

Stop further writes before you assess the blast radius.
2

Export or list the affected records

Build a view or export of the records the workflow touched. This gives you an exact, recoverable list of what changed. Work from that list, not from memory.
3

Identify the write block and its variable source

Open a representative run and find the block that performed the write. Trace its input variable upstream to the value that was wrong. That way your correction targets the cause rather than one symptom.
4

Correct the data manually or with a controlled script

Fix the affected records by hand for a small set, or with a reviewed script for a large one. Verify a few records by eye before you trust a bulk correction.
5

Add an idempotency guard before republishing

Switch a blind create to Create or update record with a matching attribute. A re-run then updates the existing record instead of creating a duplicate. Or stamp processed records with a timestamp, or filter on whether the target already exists. Each of these makes running the workflow twice safe.

​
Recovering from an external app failure

An external app failure is a run that fails inside a block that calls a connected app, rather than inside Attio’s own logic. That covers a Send HTTP request call, a Slack message, or an Enroll in sequence step. Confirm the credential and the payload first, because the fix differs from an internal data bug.
1

Check the connected app credential

Confirm the connection the block uses is still valid. A revoked token, an expired key, or a disconnected Slack workspace shows up as a failure in the calling block. It does not show up as a configuration error on the canvas.
2

Inspect the request payload or recipient

Open the failed block’s Inputs and read the exact payload it sent or the recipient it targeted. A sequence enrollment that targets a record which is not a person fails inside this block. So does an HTTP request with a malformed body.
3

Retry from failed when earlier writes must not repeat

If the workflow already wrote data successfully before the failed external call, use Retry from failed. It resumes at the failed block and skips the completed ones. So it avoids double-writing the records that already succeeded.
4

Trigger a new run when the logic changed

If you edited the workflow to fix the cause, a retry replays the old version. Trigger a fresh run instead to exercise your change.

​
Running the weekly review

A short weekly review is the cheapest way to catch problems before they page you. I run it every week for the first month after any new workflow goes live. Each item in this checklist is a place a silent failure hides.
  • Failed runs. Anything red that nobody noticed. There is no automatic retry, so a failed run stays failed until a human acts.
  • Expensive runs. Runs whose credits consumed sit well above the typical per-run cost. This is often the first sign of an unscoped trigger or a loop.
  • Paused runs. Runs left paused mid-execution and never resumed or cancelled.
  • High-volume triggers. Workflows firing far more often than their business event should warrant.
  • Newly disconnected apps. Connected integrations whose credentials lapsed and now fail every run that calls them.
  • Workflows edited but not published. Drafts with pending changes that the live version is not yet running.
For naming, ownership, and review cadence beyond the first month, follow workflow governance. For the per-run and monthly credit math behind the “expensive runs” check, see credits & pricing explained.

​
See also

Source: Attio Help Center: Troubleshooting workflows. Last reviewed against the Attio Help Center, June 2026.