Uptime monitoring

A page that is down when a crawler or an AI agent fetches it cannot be cited, and every paid click that lands on a broken page is wasted spend. Audit → Uptime checks your domain and its key pages on a schedule, opens an incident when they fail, and alerts the people who need to know. It also covers SSL certificates, DNS and domain expiry, the jobs that run behind your site, and the public status page your customers look at.

Uptime monitoring is available from the Starter plan: 5 monitors on Starter, 20 on Pro, 200 on Premium, unlimited on Enterprise. See plans and limits.

Add a monitor#

1. Open Uptime and click Add monitor

   Go to Audit → Uptime → Monitors and click Add monitor.

2. Choose the type and target

   • HTTP. A URL; leave it empty to monitor the homepage. Set the expected status codes (default 2xx) and optionally a keyword that must appear on the page, or must not (“Fail when the keyword IS present”).
   • TCP. A host and port.
   • DNS. A hostname, record type and the values that must all be present in the answer.
   • Transaction. A sequence of HTTP steps, each with its own URL, maximum response time and values extracted from JSON or headers for later steps (for example, log in, then call an API with the token).

3. Set the interval and thresholds

   Pick a check interval: every minute, 5, 10 or 30 minutes, or every hour. One-minute and five-minute checks need Pro or higher; Starter checks at most every 10 minutes. Set a Degraded threshold in milliseconds and an optional SLA target (%) between 90 and 99.999.

4. Choose who gets alerted

   Notification recipients are workspace members who get an email when the monitor goes down and when it recovers (default: the workspace owner). Add up to five Slack or Webhook channels, with an optional signing secret for webhooks, and use Test to send a test notification. Under Advanced settings you can set the request method, custom headers and body, alert on degraded checks, and repeat alerts while an incident stays open.

How incidents work#

• Up, Degraded, Down. A check slower than the degraded threshold is Degraded: still a success, never an incident, alerted only if you turn that on.
• Two failures open an incident. A single failed check is confirmed before anything happens; an incident opens only after two consecutive failures, which filters out one-off blips.
• One success closes it. The first successful check resets the failure count and resolves the incident.

Each monitor page shows 24-hour availability in 15-minute cells, 90-day availability by day, response time and size per check, recent checks with forensic details (response headers, body excerpt, transaction steps), and the incident list, where you can acknowledge incidents and add comments. The Technical health panel adds SSL certificate validity and days to expiry, DNS resolution and domain registration expiry.

Heartbeats#

Uptime checks probe your server from outside, so they cannot see a nightly backup or import that silently stopped running. Heartbeats flip the direction: your job calls a unique ping URL after every successful run.

0 2 * * * /usr/local/bin/backup.sh && curl -fsS https://<your ping URL>

Set the Expected interval and a Grace period in seconds. If no ping arrives within interval plus grace, an incident opens and you are alerted. Copy the exact ping URL from the heartbeat’s page; Reset token issues a new one and the old one stops working immediately. A heartbeat can also be embedded in a web page as a visitor pixel, a status badge or a 24-hour or 90-day availability chart.

Maintenance windows#

Planned work should not count as an outage. Maintenance windows suppress incident changes and exclude the time from uptime math. A window can be one-time, daily or weekly, and scoped to one monitor, a domain or the whole workspace.

Status pages and SLA report#

• Status pages. Publish a customer-facing page for the monitors and heartbeats you choose, showing live incident state. Visitors can subscribe to availability updates by email. Toggle Published to make it public.
• SLA report. Monthly uptime per monitor and heartbeat with maintenance excluded, against each monitor’s SLA target: uptime, downtime, incidents, longest incident, whether the SLA was met, and how much of the downtime budget is used or left. Download it as CSV for customers or internal reporting.

Worked example#

A 99.9% target over a 30-day month allows 30 × 24 × 60 × 0.1% = 43.2 minutes of downtime. Two incidents of 12 and 9 minutes use 21 minutes, leaving about 22 minutes of budget. A 60-minute maintenance window that month does not count against it.

Related#