Capture and replay webhooks with Postgres, Slack, and PagerDuty

Description

Quick overview
This workflow captures and stores incoming webhooks in Postgres, then lets you list, recover, and replay events (with optional dry-run and transforms) via a control webhook, while sending Slack and optional PagerDuty alerts when failures or backlog thresholds are exceeded.

How it works
Receives requests from the ingest webhook, control webhook, a scheduled backlog sweep, or a manual trigger.
Ensures the required Postgres tables exist and loads recent webhook history and backlog statistics from Postgres.
Determines whether the run is an ingest, control, or sweep action and builds runtime configuration (including alert thresholds and target overrides).
For ingest or recover actions, normalizes the incoming payload(s) and upserts the webhook event records into Postgres with full request context.
For replay actions, selects events by IDs or filters, optionally applies a transform, and prepares the outbound HTTP requests (or generates dry-run results).
Executes persistence updates in Postgres to record replay attempts, update event statuses, and log a replay run summary.
Sends alerts to Slack via an incoming webhook and optionally triggers PagerDuty via its Events API when replay failures spike or backlog exceeds thresholds, then returns a JSON summary response.

Setup
Add Postgres credentials and ensure the database user can create tables and read/write to the webhook_events, webhook_replay_attempts, and webhook_replay_runs tables.
Update the CONFIG values in the code step (for example Slack webhook URL, PagerDuty routing key, maxConcurrency, and defaultTarget/targetUrl strategy).
Activate the workflow and copy the production URLs for the ingest (/webhook-replay-ingest) and control (/webhook-replay-control) webhooks into the systems that will send events and manage replays.
If you enable PagerDuty alerts, set pager.enabled to true and provide a valid PagerDuty Events API v2 routing key.