Automation Failure Notifications

StackJack can email you whenever one of your automations ends badly, so you don't have to watch Run History to catch problems. You turn notifications on per automation and choose the address that receives them — the email names the automation, says exactly how the run ended, includes the error detail, and links straight to the run's detail page.

Turning it on

The setting lives with the automation's other guardrails, in both the Advanced Builder and the Edit Automation form:

1. Enable Notify on failure.
2. Enter the notification email address. It can be any address — a shared inbox, an on-call alias, a ticketing address — it does not have to be a StackJack team member.
3. Save (or deploy) the automation.

The address is validated for basic plausibility when the toggle is on. If you switch the toggle back off, the stored address is cleared, so re-enabling later means re-entering it.

The Review step of the Advanced Builder shows the current setting ("Notify on failure: address" or "Off") so you can confirm it before deploying.

When an email is sent

A notification is sent when a run reaches a non-completed terminal state — that is, any final outcome other than success:

This is deliberately the widest definition of "something went wrong": a run you cancelled yourself still generates an email, because from the notification's point of view the run did not finish its work. If you routinely interrupt runs and don't want emails for those, leave failure notifications off for that automation.

Crash-recovered runs are covered too: if a run was stranded by a service interruption and later recovered into a Failed state, it still triggers the same notification.

Operator diagnostic runs are excluded. When StackJack staff run your automation for support or diagnostics, that run is tagged as operator-initiated and never sends a tenant failure email — it isn't your automation firing on its own trigger.

What the email contains

• A headline and subject line that name the actual outcome (failed / timed out / ran out of credits / interrupted) rather than a generic "failed".
• The automation's name.
• The error or stop detail captured for the run (or a neutral "No detail was captured for this run." when a run ended before any detail was recorded).
• A link to the run detail page so you can open the full transcript in one click.

Grouping and rate limits

So a flapping automation — or a bad afternoon across your whole tenant — can't bury your inbox, StackJack groups and caps alert emails:

• Per-automation hourly digest. The first failure of an automation emails immediately and opens a 60-minute window. Further failures of the same automation inside that window are recorded but do not each send an email — they collapse into that first alert. After the window closes, the next failure starts a fresh alert.
• Per-tenant daily cap. Across all your automations, StackJack sends up to about 10 failure alerts per UTC day. When that cap is reached, you get a single "failure alerts muted until tomorrow" notice, and further failures for the rest of the day are recorded silently. Alerts resume automatically at the start of the next UTC day.

These limits only affect emails — every failed run is still recorded in full in Run History and on the run detail page, whether or not an alert was sent. If you need to watch a noisy automation closely, use those pages rather than your inbox.

Delivery guarantees

• At most one email per run — a delivery retry never becomes a second email.
• Reliable delivery. If the email provider is briefly unavailable, delivery is retried with increasing backoff before the alert is marked failed, so a transient hiccup doesn't silently drop your alert.
• Notifications are best-effort operational alerts, not a billing or audit record — the authoritative history is always Run History and the Run Detail page.

Related pages

• Run History
• Run Detail: Live Stream, Interrupt, and Transcripts
• Run Lifecycle and Statuses