Uptime Monitoring Glossary

A notification sent the moment monitoring detects a problem (or a recovery) so you can act fast.

Monitoring an API endpoint's availability, correctness, and response time — not just whether the host is up.

The degree to which a service is usable when people need it, usually expressed as an uptime percentage.

How often a monitoring tool tests your service — and the biggest factor in how fast you detect downtime.

Any period when a service is unavailable or not responding correctly to users.

The percentage of requests or checks that fail rather than succeed.

The HTTP status code a monitor treats as healthy — anything else marks the check as down.

Alerting when a scheduled job fails to check in on time — monitoring things that should happen, not URLs.

The type of HTTP request a monitor sends — GET, HEAD, or POST — depending on what the endpoint needs.

Monitoring a service by sending HTTP(S) requests and checking the response status, time, and content.

A tracked record of a disruption — from detection through resolution — with a timeline of what happened.

Checking that a page's response contains (or doesn't contain) specific text, not just that it returns a 200.

A scheduled period of planned downtime where alerts are suppressed and your status page shows maintenance.

Where in the world a check runs from — which affects latency readings and how outages are detected.

The average time a service runs normally between one failure and the next.

The average time it takes to restore a service after an outage begins.

A specific event where a service becomes unavailable or stops functioning correctly.

Checking whether a host is reachable on the network using ICMP echo (ping) requests.

Checking whether a specific network port is open and accepting TCP connections.

How long a service takes to respond to a request — a key signal of performance and early degradation.

Re-checking a failing endpoint to confirm a real outage and avoid alerting on a single transient blip.

A commitment to a level of service — most often an uptime percentage — with consequences if it is missed.

The actual measured metric — like uptime or success rate — that you compare against your SLO and SLA.

An internal reliability target you set for a metric like uptime — usually stricter than your public SLA.

Watching your HTTPS certificates so they don't expire or break and take your site down.

A public page that shows the current and historical status of your services to users and customers.

Proactively simulating requests to a service on a schedule to detect problems before real users do.

How long a single check waits for a response before giving up and marking the endpoint as down.

The percentage of time a service is available and responding correctly.

Automatically checking whether a service is online and responding, and alerting you when it isn't.