All docs

Monitoring & alerting

Uptime monitors and SLA

Uptime monitors check your sites, APIs, ports and cron jobs from outside the server, independent of the agent. This page covers the six check types, how often they run, when a failure becomes an alert, SSL and domain expiry, and how to track an SLA target with a budget and a PDF per period.

Check types

Open Uptime in the Monitor menu and click Add. Give the check a name and pick a type.

TypeTargetPasses when
HTTP(S) / API / keywordA URLThe response status is 200–399, or exactly the status you set. Optionally the body must contain a keyword. You can set the method, headers and a body for APIs.
TCP porthost:portThe port accepts a connection.
Ping (ICMP)A hostname or IPThe host answers a ping.
DNS recordA hostnameThe record type you choose (A by default) resolves, optionally containing an expected value.
Domain expiryA domainThe registration is not about to lapse (checked via RDAP).
Heartbeat / cronNothing to reach — your job calls usYour job pinged the heartbeat URL on time.

Intervals and confirmation

Checks run every 30 seconds, 1, 5 or 15 minutes, every hour or every day. HTTPS checks also read the certificate.

A single failed check never alerts. A monitor is declared DOWN only after 2 consecutive failures, and the outage is backdated to the first failed check. Until the second failure the monitor holds its previous state. When it passes again it is UP immediately, and you get an info alert that it recovered. Both transitions go to your notification channels under the Uptime category.

SSL and domain expiry

For an HTTPS monitor, Opservo warns when the certificate has 14 days or less left, and again every 7 days while it stays inside that window. Within 3 days the alert becomes critical. A Domain expiry monitor does the same for the registration, starting 30 days out.

Cron heartbeats

A heartbeat monitor is a dead-man’s switch for a scheduled job. Choose how often the job is expected (every 5 or 15 minutes, hourly, every 6 hours, daily) and how late it may be before you are alerted (1, 5, 15 or 60 minutes). Opservo gives you a unique URL. Add a call to it at the end of the job:

At the end of a cron job
curl -fsS https://api.getopservo.com/api/v1/uptime/heartbeat/<token>

GET, POST and HEAD all count. If no ping arrives within the interval plus the grace period, the monitor goes DOWN and you are alerted. The next ping brings it back UP.

Checking private targets from a server

A TCP monitor can run from one of your servers instead of from the Opservo cloud: in the form, change “Check from” to a server. Use this for targets our cloud cannot reach, such as a database on a private subnet. The agent must have probes enabled on that server. See Agent-based probes for the switch and the limits.

SLA target and window

Any monitor can carry a promised availability. Open the SLA column on the Uptime page for a monitor, pick a target (99.5, 99.9, 99.95, 99.99 or a custom value) and a window: calendar month, calendar quarter or calendar year, all in UTC.

  • •Achieved % is computed over the part of the period the monitor has existed. A monitor younger than the period is marked partial.
  • •Budget is the downtime the target allows for the full period. The panel shows how much of it is used and how much remains.
  • •The monitor’s incidents in the period are listed with their durations, and the previous 12 periods are shown underneath.

Budget alerts

Once 80 % of a period’s downtime budget is used, Opservo raises one warning for that monitor and period. If the first time it looks the budget is already fully spent, that single alert is critical and says the SLA for the period can no longer be met. There is one alert per monitor per period, never a repeat.

PDF per period

Each period in the SLA panel has a PDF button. The one-page report shows the target, achieved availability, budget used, and every outage with start time and duration, for the current or any previous period.

What is kept and for how long

  • •Check results (every pass/fail with latency) are kept for 30 days. They drive the 24-hour and 30-day uptime percentages and the response-time charts.
  • •Outage episodes (each confirmed DOWN → UP) are kept permanently. They are the source of truth for SLA math, so a yearly SLA stays correct long after the raw checks are gone.

Last updated 2026-10-01. Found a mistake? Email hello@getopservo.com.