Your n8n Failure Alert Never Fired: Test the Pager, Not Just the Workflow

Description and use

In n8n, alerts failed because they listened to workflow events instead of job state. A state‑based query and delivery tests to Slack were added, and alerts were streamlined to reduce noise.

Problem

Alerting on workflow failures missed jobs that were parked in a review state, and alerts could silently fail to reach the intended channel.

Outcome

The system now reliably alerts on jobs stuck in review state, verifies alert delivery, and reduces noise by sending concise, tiered messages.

Workflow

• 1. Schedule a query on the jobs table to count review rows older than 1 hour. 2. If count > 0, send a page to the alert channel. 3. Run a monthly drill: insert a fake review row, wait for the SLA window, confirm the message appears in Slack, then delete the row and confirm silence. 4. Keep the alert workflow on a separate instance or service to avoid shared failure.
• 5. Include only actionable information (job id, provider, last error, reconciliation handle, link to review row) in the alert message. 6. Tier alerts: urgent actions page immediately; non‑urgent actions go into a daily digest.

Evidence

I had an alert: n8n's workflow-failure trigger would ping me on Slack whenever a workflow failed.

Source

The first failure was subscribing to the wrong signal. My alert listened for workflow failures. But a job landing in review is not a workflow failure — it is a workflow succeeding at deciding "I don't know."

Source

So I alert on state, not on events. A scheduled sweeper queries the queue itself: SELECT count(*) FROM jobs WHERE state = 'review' AND updated_at < now() - interval '1 hour';

Source

The second failure was the channel itself. Even a correctly triggered alert can die between n8n and your eyes: a rotated Slack webhook token, a channel that got archived...

Source

Put a fake row in review, wait for your SLA window, and check with your own eyes that the message arrived where you actually look.

Source