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

> The moment one of your production services fails on Render, your on-call engineer gets paged and the whole team sees it in Slack.

- Workflow type: code
- Services: Render, PagerDuty, Slack
- Categories: Engineering
- Published: 2026-08-09

## What it does

- Reacts the moment a service stops running on Render, covering both runtime failures and underlying hardware failures.
- Checks the failed service against your own list of production services, so staging and side projects never wake anyone up.
- Pages your on-call engineer for genuine production outages and attaches the service type and a direct link to the service in Render.
- Posts every failure to your incidents channel in Slack, stating which service went down, when, and whether anyone was paged.

## What you'll need

- A Render account running the services you want to watch
- A PagerDuty account with an on-call schedule already set up
- A Slack workspace and a channel where incidents are posted
- A short list of which of your service names count as production

## Prompt

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.

## How to customize

- Edit the production list, and choose which PagerDuty service each one should page. This is the main knob and it lives in one obvious place at the top of the workflow.
- Change the urgency of the page, the wording of the alert, or the Slack channel it gets posted to.
- Extend it to close the incident automatically when the service comes back up, so nobody has to tidy up after a short blip.

## FAQ

### Will this wake someone up every time a staging service fails?

No. Only services on your production list can page anyone. Anything else is posted quietly to Slack so you can still see it in the morning, but nobody gets called at 3am.

### How quickly does the page go out?

Render tells us the instant a service fails, so the incident is raised within seconds rather than waiting for someone to notice an email.

### What happens to services that are not on my production list?

They skip paging entirely. You still get a Slack message saying the service failed and that no one was paged, so noisy staging failures stay visible without being disruptive.

### Do I need to change anything in my application code?

No. This works from your Render account and your existing services. There is nothing to install or add to your app.

### Can it also tell us when the service recovers?

Yes. Render reports recovery as its own event, so a common addition is closing the matching PagerDuty incident automatically once the service is healthy again.

Use this prompt in General Input: https://www.generalinput.com/prompts/page-on-call-when-a-production-service-goes-down-on-render