# Read the error headers first

When Cloudflare itself generates an error page (not your origin), the response includes two diagnostic headers. Check these before anything else, because they name the system at fault:

- **`cf-error-type`**: the error category.
- **`cf-error-origin`**: which Cloudflare system generated the error.

They are present **only on Cloudflare-generated error pages**. If they are absent, the error came from your origin and Cloudflare is just passing it through: debug the origin.

## The values that matter

- `1101`: Worker threw an unhandled exception. Look at `wrangler tail`, not the origin.
- `1102`: Worker exceeded CPU or memory limits. Your code is too heavy for the isolate.
- `52x` (521, 522, 523, 524, 525, 526): origin connectivity. The origin is down, slow, unreachable, or its TLS is broken.
- `1000`: DNS resolution failure, typically an A record pointing at a Cloudflare IP.
- `1016`: origin DNS error, typically a CNAME target that does not resolve.

## How to capture them

`curl -v mount https at //example.com` and look for `cf-error-type` in the response headers. Or use browser DevTools (Network tab, failing request, Headers) or a HAR export. Reproduce the error first: the headers only appear on the failing response.

## Checklist

- Headers present -> trust cf-error-type to pick the system (Worker, origin, DNS).
- Headers absent -> the origin generated this; do not waste time on Cloudflare config.
- Write the header value into the incident ticket. It cuts the "is it Cloudflare or us" debate to one line.