How often can ServerInspector check my site?

From every 60 seconds up to once an hour. One-minute checks are available on paid plans; the free plan supports longer intervals with the same check types and alerting.

Will I get false alerts if my server has a brief hiccup?

No. A failing check is confirmed with additional attempts before the monitor is marked down, so isolated timeouts and single dropped packets do not trigger a notification.

Does uptime monitoring also cover SSL and domain expiry?

Yes. Every HTTPS monitor records certificate issuer and expiry, and the root domain is tracked for registrar expiry with reminders at 30, 14, 7 and 1 day.

Can I monitor an internal service that is not on the public internet?

Checks run from the public internet, so the target must be reachable externally. For internal services, expose a minimal health endpoint or use an authenticated API check.

Is there a free uptime monitoring plan?

Yes. The free plan includes 10 monitors with uptime, SSL and domain tracking and alerts, for commercial sites too, with no credit card required.

Uptime monitoring

Uptime monitoring that catches outages before your customers do

ServerInspector (Server Inspector) runs synthetic checks against your websites, servers and APIs as often as every 60 seconds, confirms failures before alerting, opens an incident automatically and tells you the moment service is restored.

HTTP(S), TCP port, ping and keyword checks
Intervals from 60 seconds to one hour
Confirmation retries to suppress false alarms
Automatic incident open and resolve
Alerts by email, Slack, Discord, Telegram or webhook, confirmed before they fire
Response-time history over 24 hours, 7 and 30 days

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: a TCP reachability check on the host - no ICMP, so it works where ping is filtered.

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.

One set of alert addresses for the whole account, so nothing is configured monitor by monitor.
Add as many addresses as you need - an on-call inbox, a colleague, a shared mailbox - each confirmed before it receives anything.
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.

Frequently asked questions

Guides

Webhook Reliability: A Guide to Never Missing an Event
Webhooks from services like Stripe or GitHub are critical. Learn how to build resilient webhook handlers, monitor their uptime, and implement strategies like idempotency and retry queues to ensure you never miss a critical event.
Monitor Security Headers: CSP, HSTS, & More
Your site can be 'up' but still insecure. Learn how to use uptime monitoring checks to enforce security headers like Content-Security-Policy (CSP), HSTS, and others to prevent silent security regressions.
Monitoring Third-Party APIs: A Survival Guide
Your service relies on external APIs for payments, email, or auth. When they go down, you go down. Learn a multi-layered strategy to monitor third-party dependencies and avoid being the last to know.

All guides →

Know before your customers do

ServerInspector checks your sites, certificates, domains and APIs 24/7 and alerts you the moment something breaks. Free plan, 60-second setup.