# How Pagerless works

> One real night, minute by minute: what Pagerless sees, what it decides, and the one thing it asks of you.

URL: https://pagerless.dev/how-it-works
Updated: 2026-10-22

## The night

| Time | What happens | Who does it |
| --- | --- | --- |
| 3:08 | You (or your AI) shipped an update at dinner. It reaches users now. The deploy marker records release `a41c9e`. | Your host |
| 3:09 | Checkout calls to Stripe start failing. The SDK groups them into one problem: same error, same route. | Pagerless SDK |
| 3:09 | Payment errors pass the floor: 3 or more, and at least 2% of payment requests. Floors always wake someone. | Pagerless |
| 3:10 | The AI helper reads the scrubbed samples and the recent deploys: payments started failing 1 minute after the 3:08 update. | AI helper |
| 3:10 | Your iPhone gets a push: "Payments down since the 3:08 update. Undo it?" with **Approve** and **Take over**. | Pagerless |
| 3:11 | You tap Approve and confirm with Face ID. Undoing a deploy always needs a passkey. | You, 9 seconds |
| 3:11 | Pagerless rolls back to the previous deployment through your host's API. | Pagerless |
| 3:16 | It watches the error rate for 5 minutes. Payments are back to normal, so the problem closes. | Pagerless |
| 8:00 | The problem page says what broke, what was done and what to fix in the code before you ship again. | AI helper |

```
FIXED. 6 MIN
YOU SPENT 9 SEC
```

If you had not tapped within 5 minutes, Pagerless would have called you, then your backup.

## What Pagerless does with every error

1. **Collect** The SDK, OpenTelemetry, CloudWatch alarms or your own HTTP calls send errors, status codes, heartbeats, deploys and job check-ins. Secrets are scrubbed in the SDK and again on the server.
2. **Group** Errors with the same type, stack frames and route become one problem, so 400 identical errors are one alert, not 400.
3. **Decide** Each problem gets a level: **wake**, **tell** or **log**. Floors (app silent, crash loop, 5xx burst, payments failing) always wake. Otherwise the AI helper decides, and when it is unsure or slow the answer is tell, never log.
4. **Explain** The helper writes what broke and why in plain words, from the samples and recent deploys, and proposes a fix: undo the update, restart, add capacity, or a step for you or your coding agent.
5. **Reach you** Wake: push first, a phone call after 5 minutes without a tap, then the next person. Tell: one message, held until your quiet hours end.
6. **Fix and verify** Fixes your rules allow run alone. Risky ones wait for your approval. After any fix Pagerless watches the error rate, and if it did not help, it wakes a person rather than trying something else.

## What it will never do

- Play down a floor signal. App silent, crash loop, 5xx burst and payments failing always wake someone.
- Change your data. Data changes are always "never" in the rules, whoever asks.
- Undo a deploy without a passkey (Face ID, Touch ID or a security key).
- Follow instructions found inside error text. App data is treated as untrusted and fenced off from the model.
- Read AI-written text aloud in a phone call. Calls use fixed wording.

## Questions

### What if I don't answer?

Wake alerts push first. If nobody taps I'm on it within 5 minutes, Pagerless calls. If the call is not answered, it moves to the next person in your order, and so on.

### Does the AI decide everything?

No. Floors are fixed rules the AI cannot override, your rules decide which fixes may run alone, and an unsure or failed decision always becomes tell, never log.

### Which AI model is it?

Claude by Anthropic. App data sent to it is scrubbed first and is not used for training.