# Workflow: 5xx incident response

## Minute 0-1: read the headers

`curl -v` the failing URL (or DevTools Network tab) and read `cf-error-type`:

- **Absent**: the origin generated this error. Debug the origin; Cloudflare config is not the cause.
- **1101**: Worker threw an exception. Open `wrangler tail`, reproduce, read the stack.
- **1102**: Worker exceeded CPU/memory. The code is too heavy; this is a performance incident.
- **52x**: origin connectivity. Branch below.

## 52x branch

- **521**: origin refused the connection (down or firewall).
- **522**: connection established, no ACK in 90s. Check the origin firewall for blocked Cloudflare IPs first.
- **523**: origin unreachable (routing). Check DNS origin IP and network routes.
- **524**: origin too slow (125s timeout). Check for a runaway query or overloaded origin; consider status polling for the long endpoint.
- **525/526**: origin TLS broken. Check the cert; never "fix" by dropping to Flexible.

## During the incident

- Do not purge everything reflexively; it hammers the origin and worsens 52x incidents.
- If the origin is down and a cached copy exists, a temporary Cache Rule serving stale can buy time (separate advanced setup; know whether you have it before the incident).
- Record the cf-error-type value in the incident ticket.

## After

Write the postmortem around the header value: it already classified the fault. Add the missing monitor: origin firewall allowlists drift, certs expire, slow queries grow.

## Checklist

- Headers first, always. The taxonomy (origin / cloudflare / ssl / worker categories) routes the response.
- Each 52x has a different owner: 522/523 network, 524 app, 525/526 TLS.