Uptime Monitoring

Check your endpoints for availability and get instant downtime alerts

Uptime Monitoring pings your URLs on a schedule from multiple global regions. When your endpoint stops responding or returns an unexpected status code, Sentry opens an issue and alerts your team — before your users report it.

How it works

Sentry’s infrastructure sends HTTP requests to your URL at the interval you configure. Each check records:

• Whether the request succeeded or timed out
• The HTTP status code returned
• Response time

If a check fails, Sentry opens an uptime issue. When the endpoint recovers, the issue resolves automatically.

Setting up a monitor

1. Open Uptime Monitoring

   In your Sentry project, go to Alerts in the left sidebar, then select the Uptime tab.

2. Add a monitor

   Click Add Uptime Monitor.

3. Configure the URL and request

   Fill in the monitor details:

   • URL — the endpoint to check (up to 255 characters)
   • HTTP method — GET, HEAD, POST, PUT, PATCH, DELETE, or OPTIONS. Use HEAD for endpoints where you don’t need the response body.
   • Headers — any HTTP headers to include with each request (e.g. Authorization, Accept)
   • Body — a request body for POST or PUT checks
4. Set the interval

   Choose how often Sentry checks your endpoint:

   Interval	Seconds
   1 minute	60
   5 minutes	300
   10 minutes	600
   20 minutes	1200
   30 minutes	1800
   1 hour	3600

5. Configure alerting

   Attach an alert rule to the monitor to get notified when it goes down. You can route alerts to:

   • Email
   • Slack
   • PagerDuty
   • Microsoft Teams
   • Webhooks
6. Save

   Click Save. Sentry starts checking your endpoint immediately.

Global regions

Sentry runs uptime checks from multiple regions around the world. Checks are distributed across active regions so that a single regional network issue doesn’t trigger a false alert. If your endpoint is down in all regions, you get notified.

Regional check distribution uses a round-robin schedule across active regions. Region availability depends on your Sentry plan.

Failure detection and response capture

When a check fails, Sentry captures the full HTTP response — headers and body — so you can see exactly what your server returned. This response capture is attached to the uptime issue and helps you debug failures without having to reproduce them manually.

Response capture is enabled by default. Sentry captures the response on the first failure and then disables further captures to reduce bandwidth. You can re-enable response capture from the monitor settings.

Timeout behavior

Each check has a timeout (in milliseconds) after which Sentry considers the request to have failed. If your server accepts the TCP connection but doesn’t send a full response within the timeout window, the check is marked as failed.

Uptime issues

When a monitor detects a failure:

1. Sentry opens an uptime issue in the Issues section
2. The issue title identifies the URL and the failure type (connection failure, timeout, unexpected status code)
3. You receive alerts through any configured notification channels
4. When subsequent checks pass again, the issue auto-resolves

You can find all uptime issues by filtering Issues with issue.category:uptime.

Automatic monitoring (auto-detection)

Sentry can automatically detect URLs used in your JavaScript frontend or backend integrations and suggest them for uptime monitoring. When auto-detection is active for your organization, Sentry may create monitors automatically for domains it sees in your application’s outbound requests.

Use HEAD as the HTTP method for lightweight checks on endpoints that serve large response bodies. Most web servers respond to HEAD requests correctly and the check completes faster.

Configuration reference

Field	Description
url	The URL to monitor (max 255 characters)
method	HTTP method: GET, POST, HEAD, PUT, DELETE, PATCH, OPTIONS
headers	JSON array of {"name": "...", "value": "..."} header objects
body	Request body text (for POST / PUT checks)
interval_seconds	Check frequency: 60, 300, 600, 1200, 1800, or 3600
timeout_ms	Request timeout in milliseconds
response_capture_enabled	Whether to capture response body and headers on failures