n8n Checkpoint Resume Workflow: Postgres + Slack Alerts

Restart failed n8n pipelines automatically with Postgres checkpoints + Slack alerts

This n8n workflow implements a checkpoint-and-resume system for multi-stage executions. It stores each stage’s outputs in Postgres, automatically resumes failed or stalled runs, and sends Slack alerts when stages fail or recovery completes.

What this workflow does

• Starts runs via Manual Trigger, a webhook (POST request), or a schedule that runs every 10 minutes to sweep for resumable executions.
• Ensures required Postgres tables exist for runs, checkpoints, and run events.
• For scheduled sweeps, queries Postgres for failed runs whose retry time has passed or for running runs whose lease has expired, then calls this workflow’s webhook to resume each run.
• For manual/webhook runs, loads run state and completed checkpoints from Postgres, restores prior stage outputs into context, and determines the first stage that still needs to run.
• Uses a lease-based lock in Postgres to ensure only one execution owns the run; if the run is already completed or locked elsewhere, it exits.
• Executes pipeline stages in order (validate order, reserve inventory, charge payment, create shipment, send confirmation), saving a Postgres checkpoint and run event after each successful stage.
• On failure, retries the stage inline with exponential backoff when allowed; otherwise marks the run failed/dead-lettered in Postgres and sends a Slack alert.
• On completion, marks the run completed and finalizes status in Postgres.

Use cases

• Resuming long-running SaaS workflows after transient errors (e.g., payment or shipping failures).
• Preventing duplicate processing using Postgres lease locks.
• Providing operations visibility with Slack failure/recovery alerts for checkpointed n8n executions.

Technical details

• Triggers: Manual Trigger, Webhook, scheduled sweep (every 10 minutes).
• Logic & control: if, set, code, switch, wait.
• Notifications: Slack node for stage failure/dead-letter and alerting.
• Persistence: Postgres tables for runs, checkpoints, and run events; lease-based locking for safe checkpointed resume.