Page on-call when a production service goes down on Render

Run this as a webhook workflow that receives service events from Render. Render sends an event for everything that happens to a service, so the first step is to narrow it down: only continue when the event type is server_failed or server_hardware_failure. Exit immediately and do nothing for every other type, including server_available, server_restarted, service_suspended, and maintenance events.

From the incoming event, read data.serviceId, data.serviceName, data.id (the Render event id, which starts with evt-), the event type, and the timestamp. Those are the only inputs the rest of the workflow needs.

Enrich the event by calling Render's Retrieve service operation with the serviceId. From the response, take the service type (for example web_service, background_worker, or cron_job) and the service's dashboard URL, so the alert can link straight to the service in Render.

Near the top of the workflow, define a plain configuration object that maps production Render service names to PagerDuty service IDs, for example { "api-prod": "PSAA1G5", "checkout-prod": "PT4KHLK" }. This is the allowlist and the routing table in one, and it is the main thing I will edit, so keep it in a single obvious place with a short comment showing the format. Any Render service whose name is not a key in that object is treated as non-production. Also expose the PagerDuty user email as configuration, since PagerDuty write operations require a From header set to the email address of a valid PagerDuty user.

If the failed service name is in that configuration, create a PagerDuty incident using Create Incident against the mapped PagerDuty service, with urgency set to high and a title along the lines of "Render service <serviceName> failed". Then attach the detail to that incident with Create Incident Note, including the Render event id, the service type, and the dashboard link.

If the failed service name is not in that configuration, skip PagerDuty entirely. Do not create an incident and do not page anyone.

In both cases, post exactly one message to a configurable Slack incidents channel. The message should state which service failed, what type of service it is, when it failed based on the event timestamp, and a link to the service in Render. It must be explicit about whether someone was paged: when an incident was created, include the PagerDuty incident number or link; when paging was skipped, say plainly that the service is not on the production list so nobody was paged. The point is that the team can see both the noisy staging failures and the real ones in the same channel, without being woken up for the former.

Keep this deterministic. There is no reasoning, judgement, or summarization step anywhere: a fixed event comes in, the allowlist decides, and the workflow fans out to PagerDuty and Slack.