Scenario · Incident triage · Slack approval
On-call triage, gated through Slack instead of a webhook
Same durable-approval mechanism as the customer-service scenario, a different domain and a different notification channel — proof the six channels httpNotifier supports are genuinely interchangeable, not just documented as such.
An alert fires, no human watching yet
A monitoring alert (PagerDuty, Datadog, anything that can send a webhook) POSTs to /messages when an error-rate threshold trips. Same channel, same mechanics, as the customer-service scenario — just a different kind of trigger.
The agent investigates
Reads recent error logs and service metrics via a read-only tool (auto-allowed — nothing dangerous about looking), and drafts a diagnosis: which service, what changed, likely cause.
The fix needs a human — via Slack this time
restart_service matches an "ask" rule. The call pends instantly, no blocking — but this agent's httpNotifier is configured for channel: 'slack', not 'webhook'. SlackNotifier posts real interactive buttons (Approve / Deny) straight into the on-call channel, not a link to click somewhere else.
The on-call engineer taps Approve, in Slack
Slack's own interactivity payload lands on a receiving endpoint the host deploys (examples/notifier-handler/slack.ts), which resolves it the exact same way any other channel would: POST /pending-approvals/:id/resolve with { "decision": "approve" }. Same resolve route as the webhook scenario — a different front door, not a different mechanism.
The fix runs, and Slack hears back
The turn resumes from its durable checkpoint, restart_service actually executes, and a plain confirmation — no buttons this time, nothing left to resolve — posts back to the same channel via httpNotifier's run_finish event.
One notifier interface, six front doors
Webhook, Slack, Lark, email, database, or Redis — whichever channel httpNotifier is configured for, the actual resolution always ends the same way: a POST to /pending-approvals/:id/resolve. Swapping the customer-service scenario's generic webhook for Slack's own interactive buttons here is a config change on the agent, not a different integration.
Want the original walkthrough? See the customer-service scenario for the same mechanism over a signed, generic webhook — including a chained second approval and the cascade-skip case — or the expense-approval scenario for email's own signed magic links.