Workflow: uptime monitors that catch real outages

TL;DR

Add the rest manually; the auto monitor does not know about your API subdomain. 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.

When to use

You are seeing this: Downtime creates issues like errors do. Use this skill when you run into "Workflow: uptime monitors that catch real outages".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

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.

Researched against live Sentry docs 2026-09-26. The uptime monitoring page (docs.sentry.io/product/monitors-and-alerts/monitors/uptime-monitoring/, final URL after redirect) documents: uptime monitoring of URLs, automatic creation of a monitor for the most frequently encountered hostname in error data, configurable request details and thresholds controlling when downtime issues are created, and distributed tracing to pinpoint errors during uptime checks.