Monitors

A monitor is one thing we check on a schedule. Create monitors in Monitors → Add monitor, or with the API.

Monitor types#

Keyword, SSL certificate and domain expiry monitors, faster intervals and more regions depend on your plan — see Pricing. When a feature is not included, the API answers 402 with code: "plan_limit".

Settings shared by all types#

How an outage is confirmed#

We never alert on a single failed check:

• Monitors checked from several regions are Down only when at least two regions currently report a failure. One region with a network problem cannot page you.
• Monitors checked from one region are Down after two consecutive failed checks.
• A monitor is Up again as soon as these conditions no longer hold. Results from a region that stopped reporting are ignored.

When a monitor is confirmed down we open an incident and alert the contacts in its alert rules.

Statuses#

Pausing and resuming are free, but a resumed monitor counts against your plan's monitor limit again.

HTTP(S)#

We send a request to the URL from each selected region and check the response. The target must be an absolute http:// or https:// URL (up to 2,048 characters).

A check fails on a timeout, a DNS or connection error, a TLS error (invalid or expired certificate) or an unaccepted status code. Requests carry the user agent IsItUpRightNow/1.0 (+https://isituprightnow.com), which you can allow in your firewall or bot protection.

Keyword#

A keyword monitor is an HTTP(S) monitor that also looks for a text in the first megabyte of the response body:

Ping#

Sends an ICMP echo request to the host and measures the round-trip time. The target is a host name or an IP address. Some networks and cloud providers block ICMP; use a port or HTTP(S) monitor for those hosts.

Port#

Opens a TCP connection to the host and port (config.port, 1–65535). The monitor is up when the connection succeeds — ideal for databases, mail servers (25, 465, 587), SSH (22) or game servers. We don't send any data.

Heartbeat (cron)#

The other way round: your job calls a unique URL every time it runs, and we alert you when a call is late. See Heartbeat monitors for the setup and examples.

SSL certificate#

Connects with TLS (port 443 unless you give one, e.g. example.com:8443) and reads the server certificate.

• The monitor is down when the certificate is expired, not yet valid, issued for another name or not trusted.
• You are alerted before it expires: config.notifyDaysBefore lists the days (default [30, 14, 7], up to 10 values between 1 and 365). Each threshold is notified once per certificate.

Domain expiry#

Looks up the registration of the domain through RDAP once a day, whatever interval you choose, and alerts at the notifyDaysBefore thresholds (default 30, 14 and 7 days before expiry). Enter the registrable domain (example.com); www. and URLs are stripped automatically. A failed lookup is retried after six hours and never marks the monitor down.

DNS#

Resolves the host from the checking region.

UDP#

Sends a datagram with config.payload to the host and port (config.port).

• With expectedResponse set, the check waits for a reply that contains this text, and fails on timeout or a different reply.
• Without it, a successful send is all we can verify (UDP has no connection), so prefer setting an expected response.

The monitors list#

Each monitor is one row:

• Status and how long: Up for 4d 8h, Down for 12m (with the failure code, for example 503 or T/O, and a link to the open incident), Paused for 3d.
• Last 24 hours: one bar per hour. Green means every check passed, amber means some failed, red means most failed; a short stub means there were no checks in that hour (for example before the monitor existed). Hover a bar, tap it or use the arrow keys to see the hour, its uptime and how many checks failed. The uptime of the last 24 hours is shown under the bars.
• Row menu (…): pause or resume, edit, send a test notification, delete.

Above the list you can select monitors for bulk actions, search by name or URL, filter by status, type and tag, and sort: Custom order, Down first, Name, Uptime (24 h) (lowest first) or Response time (slowest first). Drag and drop with the ⋮⋮ handle (or Space and the arrow keys) works in Custom order without filters, and the order is saved for your whole team.

The Current status panel counts monitors by status and shows how many of your plan's monitors you use. Last 24 hours shows the overall uptime (the average of your monitors), incidents that started, total downtime, the MTBF and how long you've been without incidents.

A monitor's page#

• Current status, Last check, Last 24 hours: status with its duration, when the last check ran and the hourly bars.
• Uptime for the last 7, 30 and 365 days and for any custom range, each with its incidents and downtime. Checks inside maintenance windows don't count. A period that starts before the monitor existed is counted from its creation (marked since … (created)). History older than your plan keeps is not available and says so.
• MTBF (mean time between failures) over 7, 30 or 90 days = the monitor's total uptime in that window (time it existed, minus maintenance and downtime) divided by the number of incidents that started in it. With no incident there is nothing to measure, so it shows No incidents.
• Response time for the last hour, 24 hours, 7 days or 30 days, with the average, fastest and slowest successful check. Long ranges are grouped into time buckets; hover the chart for the details of each point.
• Domain & SSL (HTTP(S) and keyword monitors): the TLS certificate's expiry and issuer, read during the normal HTTPS check, and the domain's registration expiry, looked up once a day through RDAP. Until they are checked the card says Not checked yet; some registries (for example several country domains) don't publish an expiry date.
• Next maintenance: the active or next maintenance window for the monitor, or a button to set one up.
• Regions: where the monitor is checked from, on a map.
• Latest incidents with their root cause: a short code (503, T/O for a timeout, DNS, SSL, KW for a keyword check, …) and what it means. Export CSV downloads the incidents and every check of the last 7, 30 or 90 days (within your plan's history).
• Test notification sends a clearly marked test alert to this monitor's alert contacts. It opens no incident and changes nothing; you can send 3 every 10 minutes. SMS and voice tests use credits.

Good to know#

• Private networks are off limits. Checks only connect to public internet addresses; hosts that resolve to private, loopback or link-local addresses fail with an "invalid target" error. This protects everyone (SSRF protection).
• Allow-listing our checkers. Use the user agent above for HTTP checks; checker IP addresses can change, so we don't recommend IP allow-lists.
• Response times are measured from the selected regions and include DNS, connection and TLS time.
• History is kept for your plan's retention period; see Pricing.