> ## Documentation Index
> Fetch the complete documentation index at: https://sentrydocs.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# 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

<Steps>
  <Step title="Open Uptime Monitoring">
    In your Sentry project, go to **Alerts** in the left sidebar, then select the **Uptime** tab.
  </Step>

  <Step title="Add a monitor">
    Click **Add Uptime Monitor**.
  </Step>

  <Step title="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
  </Step>

  <Step title="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    |
  </Step>

  <Step title="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
  </Step>

  <Step title="Save">
    Click **Save**. Sentry starts checking your endpoint immediately.
  </Step>
</Steps>

## 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.

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

## 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.

<Tip>
  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.
</Tip>

## 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                |