Skip to main content

Failure Handling

Things fail. A provider has a bad minute, a template gets suspended, a phone number is malformed. Flowera's job is to make sure a failure costs you one row rather than a campaign — and that it doesn't burn credits repeating itself.

What happens when a run fails​

Failures fall into three kinds, and the kind decides the response:

KindExampleResponse
TransientA network blip, a provider returning a 5xxRetried automatically
PermanentA broken template, a missing modelNo retry — it would fail identically
ComplianceA suppressed contact, a paused templateSkipped, deliberately

That third row is worth pausing on. A skipped row isn't an error: it's the system declining to message someone it shouldn't. Skips in a campaign report are usually the system working.

Retries​

Transient failures retry automatically, a few times, with a growing gap between attempts.

Permanent failures don't retry. They end as failed and wait for you. The batch detail view has Retry Failed, which re-runs only the failed rows of the latest fire, on their original sessions. Rows that already succeeded are untouched.

How Retry Failed avoids double-messaging

Not by idempotency — a WhatsApp send carries no idempotency key, so re-running one genuinely would send twice. Safety comes from exclusion: any row where a message was already handed to WhatsApp before the failure is left out of the retry and reported as excluded.

So a retry can come back with fewer rows than failed. That difference is the excluded set, and it's the one place a human has to look: those rows may have reached the customer already, and only you can decide whether to send again.

Fix the cause first. Retrying a row that failed because the template is broken just fails it again.

Automatic pausing​

Some failures aren't worth retrying at all, and Flowera pauses the automation instead — the Paused by system status:

Two things do this:

CauseWhy it pauses
Repeated consecutive failuresSomething is broken; each tick would waste credits. The threshold is 5 by default, and workspace Owners can change it
Canary quality dropThe first slice of a batch went badly; the rest is held back

A system-paused automation stays paused. It will not recover on its own — resolve the cause, then resume it deliberately. That's the design: an automation that resumed itself would be an automation that starts failing again while you're asleep.

The pause reason is recorded on the automation, so you don't have to guess which of the two happened.

The empty-wallet pause is different​

When the wallet runs dry mid-run, the automation is paused too — but it shows the ordinary Paused badge, not Paused by system, so it looks like a human paused it.

It also recovers by itself. Funding the wallet, manually or through auto-recharge, reactivates it and re-queues the runs it skipped in the previous 24 hours. See Low balance.

Things that notify but don't pause​

Three events raise a notification and nothing more. The automation keeps firing, so treat these notifications as work to do rather than as a stopped system:

  • A WhatsApp template paused or recategorised by Meta. Every send using it will now fail.
  • The flow behind an automation deleted. The automation isn't paused — it's deleted with the flow, along with its fire history. See Settings.
  • The workspace suspended.

Inspecting a failed run​

Work outward:

  1. The automation's fire history — which fire failed, and when.
  2. For a batch, the row list — which rows, and with what outcome. A pattern (all rows for one country, all rows missing a column) is more useful than any single failure.
  3. The execution — the node trace for that specific run, which shows exactly which node failed and what it received.

Step 3 is where the actual answer usually is. Everything above it tells you which run to open.

The dead-letter queue​

A fire that fails terminally is kept rather than discarded. The dead-letter queue lists these, and offers two actions. It's visible to workspace Owners only:

  • Replay — fire it again, with the same configuration.
  • Discard — drop it from the list once you've decided it doesn't need to run.

Replay works even on a system-paused automation, which is what makes it useful for recovery — but it doesn't resume the schedule. Resuming stays a separate, deliberate action.

warning

The dead-letter queue works at the fire level and suits single-mode automations. For batch runs, use Retry Failed instead — replaying a whole batch fire would re-send to every recipient who already received it.

Notifications​

Recovery events raise in-app notifications: an automation auto-paused, a batch finished with failures, a canary held back the rest of a send. They're how you find out about a Paused by system without watching the list.