Services & Monitors

Services and their monitors are at the heart of StatusPage / Monitoring. A Service is a logical unit — “my-website”, “checkout”, or even “my-entire-saas”. A Monitor is one concrete check against exactly one target: ping the landing page, connect to the database port, verify the TLS certificate hasn’t expired. Each service contains one or more monitors, and the service’s status rolls up from them.

flowchart TD
    S["Service: Web Shop"] --> M1["Monitor: HTTP https://shop.example.com"]
    S --> M2["Monitor: SSL certificate shop.example.com"]
    S --> M3["Monitor: Heartbeat nightly-backup"]
    M1 --> L1["🇩🇪 Nuremberg"]
    M1 --> L2["🇺🇸 Hillsboro"]
    M1 --> L3["🇸🇬 Singapore"]

Manage everything under Monitoring → Services in your Project.

Services and monitors share one status vocabulary:

How a monitor gets its status: every selected location checks independently. A location that fails reports an outage; a location that succeeds but responds slower than the degraded threshold reports Degraded. Any single location confirming an outage flips the whole monitor — there is no majority vote. “Confirming” means the new state was seen for failure-threshold consecutive checks (the very first check after Unknown flips immediately). Degraded never outranks an outage.

How a service gets its status: paused → Paused; in maintenance → Maintenance. Otherwise: all monitors up → Operational; all down → Major Outage; a mix of up and down → Partial Outage; only up and degraded → Degraded. A degraded monitor alone never escalates the service past Degraded.

Create a service with Create Service:

After creating the service, add monitors to it. On the service’s detail page you also configure alert rules and maintenance windows.

Further service actions (row menu or detail page):

• Pause / Start — a paused service stops all its checks and shows Paused. Monitors you paused individually stay paused when the service resumes. Status-page subscribers can be notified of pause/resume.
• Duplicate — pre-fills the create dialog with <name> (Copy).
• Automatic incidents — when enabled (plan feature), an incident draft is opened automatically when the service enters Partial Outage or Major Outage. Drafts that stay untouched are cleaned up after 48 hours.
• Delete — permanently removes the service and all its monitors, alert rules, and history. You must type the service name to confirm.

Open a service and click Create Monitor. Every monitor has:

Timeout, degraded threshold, and failure threshold are not part of the create form — each type starts with sensible defaults, which you can tune afterwards on the monitor’s edit page (see Advanced settings).

The interval controls how often the check runs. Available steps: 15 s, 30 s, 1 min, 5 min, 10 min, 15 min, 30 min, 60 min, 1 day.

Two minimums apply — a technical one per check type (see the summary table) and one from your plan. If you request an interval below the effective minimum, it is silently raised, never rejected.

The interval also sets the default failure threshold (how many consecutive failed checks before a monitor flips — see Advanced settings):

Fast intervals get a higher default threshold so a single network blip doesn’t page you; slow intervals alert on the first failure because waiting for confirmation would take too long.

Active checks can run from up to three locations:

• 🇩🇪 Germany (Nuremberg) — the default
• 🇺🇸 United States (Hillsboro)
• 🇸🇬 Singapore

How multi-location checking behaves:

• Each location checks independently on every cycle and keeps its own status, latency stats, and error message (visible when you expand the monitor row).
• Any one location confirming an outage flips the monitor — there is no majority vote. This catches regional problems (e.g. your site is unreachable from Asia only).
• Some types always run from Nuremberg only: DNS, SSL Certificate, Domain, DNSBL, Heartbeat (heartbeat is passive and has no location at all).
• Selecting locations other than Germany requires the Global locations plan feature.

On the monitor’s edit page (plan feature Advanced monitor settings; without it, the defaults apply):

Timeout and degraded threshold only exist for latency-measuring types — Domain and Heartbeat monitors have neither.

• Pause / Start — pausing stops checks; the timeline records Paused data points, so statistics have no gaps. Resuming resets the status to Unknown and triggers a check immediately.
• Duplicate — pre-fills the create form with all settings of the original (<name> (Copy)).
• Edit — everything except the type can change. Changing a heartbeat monitor keeps its token and last-ping time.
• Delete — permanently removes the monitor and its entire history (uptime, state changes, raw checks).

Which types are available depends on your plan. All timeouts and degraded thresholds are tunable within the advanced-settings ranges.

Sends an ICMP echo request to a host — the classic “is the machine reachable at all” check. Best as a first-line check for servers and network gear.

Up = host answers within the timeout (default 1,000 ms). Degraded = answer slower than 300 ms (default). Down = no answer or error.

Opens a TCP connection to a host and port. Confirms a service is listening without speaking its protocol — databases, message brokers, game servers, anything with a port.

Up = connection established within the timeout (default 3,000 ms). Down = refused, unreachable, or timed out.

Requests a URL and asserts on the response — the workhorse for websites and APIs. Beyond the status code you can check headers, request bodies, response content, and a JSON value.

Up = status code matches and every configured body/JSON assertion passes. Any failed assertion is down, with a precise error message per location (e.g. unexpected status 503).

Resolves a record for a host against a DNS server of your choice and compares the answer. Catches broken zone changes, expired records, and hijacked entries.

Up = all expected records found. Runs from Nuremberg only.

Performs a TLS handshake (with SNI) and reads the certificate’s expiry date. Alerts you before the certificate runs out — not when it already has.

Down also fires when the handshake itself fails (e.g. broken chain). Runs from Nuremberg only.

Checks your domain’s registration expiry via RDAP (with WHOIS fallback). The counterpart to the certificate check — an expired domain takes everything down with it.

Runs once per day (fixed), from Nuremberg, with no timeout/latency settings.

Passive: instead of TrustComponent reaching out, your system pings us — perfect for cron jobs, queue workers, and backup scripts that have no port to probe. If no ping arrives within interval + grace period, the monitor goes down.

After creation the monitor shows its secret token (prefixed hbt_) — ping the endpoint with it or with a Project API key; see the Heartbeat API for the exact URLs. If the token leaks, rotate it on the monitor page (the old token stops working immediately). A ping from a down state flips the monitor back to Operational instantly — recovery doesn’t wait for the next evaluation cycle.

Fetches a URL and verifies a substring appears in the response body. Simpler than a full HTTP monitor when “the page still says what it should” is all you need.

Up = response is 2xx and contains the keyword.

Connects to a mail server and reads its greeting banner.

Same banner check for IMAP servers.

Same banner check for POP3 servers.

Checks that an SSH daemon answers with its version banner — no login, no key exchange beyond the greeting.

Banner check for FTP servers.

Sends an NTP client packet and expects a valid server response — verifies your time source actually serves time.

Sends a datagram to a host and port, optionally with a payload, optionally expecting an answer. For custom UDP protocols.

Checks whether an IP address is listed on DNS block lists — essential for mail servers, where a listing silently kills deliverability.

All zones are queried in parallel. Up = listed on zero zones; a listing reports down with the zone name(s). Runs every 15+ minutes from Nuremberg.

A maintenance window marks a planned period in which a service is expected to be unavailable. While a window is active:

• the service (and its monitors) shows Maintenance — on the dashboard and on status pages,
• all alerts are suppressed and any firing alert rule is reset,
• no checks are dispatched; the timeline records Maintenance instead, so your uptime statistics aren’t polluted by planned downtime,
• status-page subscribers receive maintenance started / ended notifications (if they opted in).

Add windows on the service detail page under All Maintenance Windows → Add Maintenance Window:

Behavior and management:

• Enable / Disable — windows can be deactivated without deleting them (toggle in the edit dialog or the row menu). A disabled window never becomes active.
• Overlap is fine — the service is in maintenance while any enabled window is active.
• Active badge — currently running windows are marked Active in the table.
• Expired windows — one-off windows whose end has passed move to a separate Expired Maintenance Windows list; they no longer run but can still be edited (rescheduled) or deleted.
• Duplicate / Edit / Delete — via the row menu. Editing lets you rename, reschedule, and toggle Enabled; the type itself can’t change.

Planned maintenance you want to announce to customers (with updates and a timeline) is a separate concept — create a Scheduled Maintenance incident for that. Maintenance windows silence monitoring; incidents communicate.

• Uptime bars — every service and monitor page shows the last 90 days as one bar per day, colored by the worst state that day; hover for the exact per-state durations, uptime percentage, and any incidents of that day.
• Per-location statistics — for each location you see the current status, the average latency of the most recent checks, and the last error message, on the expandable monitor rows and the monitor page.
• Latest checks charts — check outcomes (up/down/maintenance/paused/no data) and a latency line chart with your degraded threshold drawn in, switchable between 1-minute, 5-minute, hourly, and daily resolution.
• Retention — how far back history reaches depends on your plan’s data-retention feature (3–24 months). Raw per-check data is kept for 24 hours and rolled up into 1-minute → 5-minute → hourly → daily aggregates.

Technical hard limits (independent of plan):

Plan-dependent: total monitor locations (the quota the badge on the Services page tracks), available check types, minimum interval (down to 15/30 s), global locations, advanced settings, and maintenance windows. See Projects & Services for how to compare and upgrade plans.