Workflow: uptime monitors that catch real outages

# Workflow: uptime monitors that catch real outages

Error tracking only fires on requests that arrive. A full outage, a DNS failure, a bad deploy that 500s everything: silence. Uptime monitors close that gap from the outside.

## 1. Cover the surfaces

Create monitors for:

- The marketing/homepage URL (the thing users hit first).
- The API health endpoint (the thing your services depend on).
- The login or checkout flow entry point (the thing that costs money when down).

Sentry auto-creates a monitor for the most frequent hostname in your error data, which usually covers the main app. Add the rest manually; the auto monitor does not know about your API subdomain.

## 2. Configure thresholds, not just URLs

Each monitor takes request details and thresholds that control when downtime issues are created. Set them deliberately:

- Check interval: 1 minute for critical surfaces, 5 for the rest.
- Consecutive failures before alerting: 2-3, so one flaky probe does not page anyone.
- Expected status and response time: assert the status code you mean (200, not just "not 500") and a sane latency ceiling.

## 3. Route downtime issues

Downtime creates issues like errors do. Assign them to the on-call rotation with alert rules, and keep them separate from error alerts so an outage does not get buried under its own error spike.

## 4. Triage with traces

Uptime checks run with distributed tracing, so a failed check links to the errors that occurred during it. When the monitor fires, follow the trace before SSHing anywhere: the root cause is often already captured.

## Verify

Take a staging endpoint down (or point a monitor at a dead URL temporarily) and confirm the full chain: downtime issue created, alert routed, trace attached. Then delete the test monitor so it does not become mystery noise in a month.