Uptime monitoring that catches outages before your customers do

What an uptime check actually measures

A synthetic check performs the same request a browser or client would: it resolves DNS, opens a TCP connection, completes the TLS handshake, sends the request and validates the response. A monitor is only reported UP when every stage succeeds within your timeout and the response matches what you expect.

• DNS resolution failures are separated from HTTP failures so you can tell a registrar problem from an application problem.
• TLS handshake errors surface as certificate problems rather than generic downtime.
• Status code and keyword assertions catch soft failures where the server returns 200 with an error page.
• Response time is recorded on every check so slow degradation is visible before a full outage.

Check types and when to use them

Different failure modes need different probes. Most teams start with an HTTP check on the customer-facing URL, then add a keyword check on a page that exercises the database and a port check for non-HTTP services.

• HTTP(S): validates status code, redirects, latency and TLS for web apps and APIs.
• Keyword: fails when expected text is missing, catching blank pages and error templates behind a 200.
• TCP port: checks SMTP, SSH, databases, game servers and any other listening service.
• Ping: verifies host reachability where ICMP is permitted.

Alerting without alert fatigue

A single failed request is not an outage. ServerInspector re-checks a failing target before declaring it down, so transient packet loss and one-off timeouts do not wake anyone. When a monitor does change state, the alert names the monitor, the failure reason, the HTTP status and the exact timestamp, and a recovery notice follows automatically.

• Global notification rules so you do not configure alerts monitor by monitor.
• Per-channel routing: email for records, Slack or Discord for the team, webhooks for your own tooling.
• Weekly digest reports summarising uptime, incidents and upcoming expirations.

Incidents, uptime percentage and reporting

Every state change writes an incident with a start time, resolution time and total duration, so your uptime percentage is calculated from recorded evidence rather than estimates. Uptime charts cover the last 24 hours, 7 days and 30 days, and the same data can be published on a public status page.