Managing monitors

Day-to-day actions on a monitor, from its detail page or the monitors list.

Pause and resume

Pause a monitor to stop checking it and stop its alerts — useful during planned maintenance. It stays in your list and keeps its history; resume picks checking back up. A paused monitor still counts toward your plan’s monitor limit, but its paused time isn’t checked or alerted on.

If a monitor is down (or degraded) when you pause it, that time still counts against its uptime and in reports, up to the moment you paused. Time after you pause isn’t counted.

You can also pause and resume from the API with a Read + Write token: POST /v1/monitors/{id}/pause and POST /v1/monitors/{id}/resume. Both are safe to repeat — pausing a paused monitor, or resuming one that’s already running, changes nothing.

Editing a paused monitor — in the app, through the API, or with Terraform — keeps it paused. Over the API, sending a read-only field such as enabled or status in an update now returns a clear error instead of silently doing nothing — use pause/resume above instead.

Where a monitor’s alerts go

Alerts are routed from the destination side, not from the monitor. A monitor’s page, and the create and edit forms, show Alerts go to: with the destinations that will alert for it, for example Email, Webhook (all monitors). It is read-only: to change it, open Notifications.

• A destination set to All monitors covers every monitor, including ones you add later.
• A destination set to specific monitors covers only the monitors picked for it. It does not pick up new monitors. After you create a monitor, add it to that destination from Notifications → ⋯ → Alert scope….

If one of your own agents stops checking in, or comes back, the alert also goes to a specific-monitors destination that covers a monitor that agent checks.

If no switched-on destination covers a monitor, its page shows an amber No alerts will reach you for this monitor. See Not getting alerts?.

Delete

Delete removes the monitor and stops its checks. This can’t be undone — its history goes with it. If it was the last monitor a destination was set to, that destination is left covering nothing and shows Not receiving until you pick another monitor.

Run a check on demand

Diagnose runs a single check right now, outside the normal schedule, and shows you the result — handy for confirming a fix without waiting for the next scheduled check. If the check fails, Diagnose says why in plain words, for example “HTTP 503 (service unavailable)” or “Request timed out”. Diagnose is available for Website / HTTP monitors that have an agent attached. You can diagnose the same monitor once every 30 seconds, and up to 10 times a minute across your account.

Heartbeat URL

For a heartbeat monitor, you can rotate its ping URL. This issues a new URL and token and immediately retires the old one — do it if the old URL may have leaked. Update your job to call the new URL.

Dependencies

On any checkpoint or platform monitor, you can pin up to 50 of your own Vendor monitors as dependencies — for example, mark your API monitor as depending on your “AWS” and “Stripe-equivalent” vendor monitors. This is context only: dependencies are shown on the monitor’s detail page so you can see at a glance whether a vendor is involved, but they never change the monitor’s own status. (Vendor monitors themselves can’t pin dependencies.)

Uptime goal (SLA target)

Give a monitor an uptime goal (for example 99.9%). This doesn’t change alerting — it’s the target that Reports measure actual uptime against, so a report can show whether each monitor met or missed its goal.