Uptime monitoring

How monitoring works

A monitor is a named HTTP(S) route attached to one of your apps: an app proxy endpoint, a webhook receiver, a health route, your public site. You’ll find them under Services → Uptime in the sidebar, grouped per app. Each monitor is checked on its own schedule:

• Interval: every 1, 5 or 10 minutes, or a custom interval from 1 to 60 minutes (plan minimums apply, see limits below)
• Request: GET or HEAD (default GET, since many servers answer HEAD with 405), with a configurable timeout of 1 to 30 seconds (default 30). With a shorter timeout the request still waits up to 30 seconds, so a late answer is reported with its actual duration. Redirects are followed; the response body is never downloaded, so latency is time to response headers
• A check passes when the final response is 2xx. After redirects are followed, a final 3xx, 4xx or 5xx counts as a fail: “up” means the route really serves content

Every monitor gets a 24-hour status timeline strip, uptime tiles for the last 24 hours, 7 days and 30 days (the share of successful checks; windows with no checks show a dash, not a fake 100%), a latency chart switchable between minute (24h raw), hourly (30 days, average + p95) and daily (1 year) resolution, and a status-code breakdown. A Test now button runs a one-off check of the configuration without recording a data point.

Incidents

One lost packet should never page anyone, so a monitor goes down after 3 consecutive failed checks. That opens an incident and sends the down alert with the reason (HTTP status, timeout or network error), when the failures started and a link to the monitor.

• The first successful check after a downtime doesn’t close the incident, it puts the monitor in Recovering. After an uninterrupted healthy period (default 10 minutes, configurable 1 to 120 per monitor) the incident auto-resolves and the recovery alert goes out with the total downtime
• A failure during the recovery period drops the monitor back to down without opening a new incident or re-alerting, so a flapping route produces one incident, not ten
• An open incident can also be resolved manually by an organization owner; if the route keeps failing afterwards, 3 fresh fails open a new incident
• Down alerts have a 15-minute cooldown per monitor; recovery alerts always send

Recent incidents are listed on the monitor detail with their start, duration, first error and whether they resolved automatically or manually.

Alerts

Down and recovery alerts have a single delivery path: your organization’s notification rules. The monitor measures; the rules decide who hears about it. Each rule delivers to its own Slack channels (through your organization’s Slack connection, with the app’s name and logo as the sender) and its email recipients.

• A rule's Uptime section lists trigger rows: name specific monitors, or add the "All monitors" row to cover every monitor in your organization
• One rule sends one alert per incident edge, even when several of its rows cover the same monitor
• A monitor covered by no rule is graphs-only; its detail page shows a warning with a shortcut to set up notifications
• The daily report adds an Uptime (24h) percentage with its day-over-day change and an incident count for every app that has monitors

Plans & limits

Downgrades never delete anything. If a plan change leaves you over the monitor limit, your oldest monitors keep running and the newest ones are marked Paused by plan limit until you upgrade, delete monitors, or enable extra monitors; a configured interval below the plan minimum stays saved and is simply checked at the plan minimum instead.

Extra monitors

Above the included count you can pay for extra monitors instead of upgrading a tier: $1 per month per extra monitor, enabled by an organization owner on the Billing page (requires an active paid subscription).

• With the opt-in enabled the monitor limit stops being enforced; the number of active monitors above your included count is recorded once per day
• Billing is prorated daily: a month's charge is monitor-days × $1 / 30, added to your next invoice. Running one extra monitor for half a month costs about $0.50
• Extra monitors don't change the plan's minimum interval
• Turning the opt-in off re-applies the plan limit (newest monitors pause again). Already-accrued monitor-days from earlier days remain billable

What can be monitored

Monitors target public HTTP and HTTPS endpoints. URLs must not contain credentials, and hostnames that are private, loopback or link-local addresses (or localhost) are rejected when the monitor is saved; DNS is re-checked before every request, so a public name resolving to a private address fails the check as blocked rather than probing your internal network.