Uptime monitoring

Uptime monitoring that detects outages in one second

PingInsight polls your endpoints as often as every second and records outages to the exact second. Where Instatus floors at 30 seconds, our 1-second engine catches incidents an order of magnitude sooner — and confirms them with multi-location quorum so you only get paged on real outages.

True 1-second checks

Configure per-monitor intervals down to one second on Enterprise. Tiered, but no other status-page tool comes close to this resolution.

Exact-second outage records

Millisecond-stamped probes mean your timeline shows “down for 4.2s,” not a fuzzy one-minute window.

14 check types

HTTP/API with assertions, ping/ICMP, TCP, UDP, DNS, SSL expiry, domain/WHOIS, SMTP/IMAP/POP3 mail, SSH, NTP, heartbeat/cron, and group checks.

Multi-location quorum

Probe from three regions and require quorum plus consecutive failures before declaring DOWN, so a single flaky network path never pages you.

Detection lag comparisonoutage1s checkscaught ~1s in5m checksmost of the outage missed
A 1-second cadence catches an outage almost immediately; coarse intervals miss most of it.

A true 1-second engine, with intervals for every plan

Most “status page” products schedule checks a minute or more apart, so an outage can run for most of a minute before anything notices. PingInsight was built around a polling engine that can fire every second, and the interval is tunable per monitor so you spend frequency where it matters.

The interval ceiling scales with your plan: Free checks every 60 seconds, Pro every 30 seconds, Business every 5 seconds, and Enterprise every 1 second. Put your checkout flow or payments API on the tightest interval, and leave a marketing redirect on a relaxed one — you control it monitor by monitor.

Web and network checks

HTTP/API checks request any URL and validate the response — status code, latency, and the body or headers — which makes them the workhorse for websites and REST endpoints. Ping (ICMP) checks confirm a host is reachable at the network layer and measure round-trip latency, ideal for routers, gateways, and bare hosts. TCP port checks open a connection to a specific port to prove a service such as a database or message broker is accepting connections. UDP port checks probe connectionless services like game servers, VPN endpoints, or syslog where there is no handshake to rely on.

DNS, SSL, and domain checks

DNS checks resolve records and verify the answer matches what you expect, catching misconfigured or hijacked records before users hit a dead name. SSL certificate checks watch the served certificate and warn you well before it expires, so a forgotten renewal never takes the site down. Domain/WHOIS checks track the registration expiry of the domain itself — the slow-motion outage that bites teams who let a renewal lapse.

Mail, SSH, NTP, heartbeat, and group checks

Mail is monitored across all three protocols: SMTP checks confirm outbound mail can be sent, IMAP checks confirm a mailbox is reachable for sync, and POP3 checks confirm legacy retrieval still works. SSH checks verify that a server is accepting secure shell connections — useful for fleets and bastions. NTP checks measure clock offset so time drift never silently breaks auth tokens, certificates, or scheduled jobs. Heartbeat (cron) checks invert the model: instead of us calling you, your job calls us on a schedule, and a missed ping raises an alert — perfect for backups, ETL, and cron. Group (aggregate) checks roll several monitors into one health signal so a single component on your status page reflects the true state of a multi-part service.

Assertions: don't just check it's up, check it's right

A 200 response doesn't always mean the service is healthy. HTTP/API checks let you assert on what actually matters: the status code, a substring or pattern in the response body, a specific JSON field, response headers, and a latency ceiling so a degraded-but-up endpoint still trips. Stack several assertions on one check and the monitor only passes when every one of them holds — turning a shallow ping into a real synthetic test.

Multi-location quorum and consecutive-failure confirmation

PingInsight probes from three live regions — us-east-2 (Ohio), us-west-2 (Oregon), and eu-west-1 (Ireland). A single region seeing a timeout is often a transient network path problem, not your service being down. So before a monitor is marked DOWN, the outage must clear a quorum of regions (at least two agree) and persist across a configurable number of consecutive failures.

That two-stage confirmation is how you get fast detection without noisy false alarms: the 1-second cadence finds problems quickly, and quorum plus consecutive failures make sure what you're paged on is real.

Exact-second, millisecond-stamped timelines

Every probe is timestamped to the millisecond, so an incident is recorded as a precise interval rather than rounded to the nearest check window. Your timeline reads “down 14:02:09.3 → 14:02:13.5, 4.2s” instead of a vague one-minute bucket. That precision flows straight into your status page, your incident duration, and the uptime math — and it's the difference between guessing at an SLO and measuring it.

Alerts and history

When an outage is confirmed, PingInsight notifies you on any of eleven channels — email, Slack, Discord, Telegram, Microsoft Teams, PagerDuty, Google Chat, ntfy, Mattermost, Rocket.Chat, and signed webhooks. Raw check results are retained for 7 days on Free and Pro, with rolled-up history kept for 365 days on Pro, 730 days on Business, and 1095 days on Enterprise so you can report on trends over a year or more.

Multi-location quorum across 3 regionsUS-EastUS-WestEU-WestDOWN confirmed2 of 3 regions agree
An outage is declared only when a quorum of probe regions agrees — at least two of the three.
# Heartbeat: have a cron job call PingInsight on success.
# If the ping is missed on schedule, PingInsight raises an alert.
0 2 * * *  /usr/local/bin/backup.sh && curl -fsS https://ping.pinginsight.com/h/<your-monitor-id>

# HTTP/API check assertions (configured per monitor):
#   - status code is 200
#   - JSON field  $.status        equals "ok"
#   - response body contains       "healthy"
#   - response time is under       500 ms
curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" https://api.example.com/health
Ping a heartbeat monitor from cron, and assert on a JSON API response.
FAQ

Frequently asked questions

How does PingInsight avoid false alarms at 1-second intervals?
Checking frequently doesn't mean alerting carelessly. Before a monitor is marked DOWN, the failure must be confirmed by a quorum of probe regions (at least two of the three agree) and persist for a configurable number of consecutive failures. A single transient timeout from one region won't page you.
Which regions do checks run from?
Three live regions: us-east-2 (Ohio), us-west-2 (Oregon), and eu-west-1 (Ireland). Outages are confirmed by multi-location quorum across them, so a localized network problem near one probe doesn't trigger a false alert.
What's the fastest check interval, and what do other plans get?
Intervals are set per monitor and scale with your plan: Free checks every 60 seconds, Pro every 30 seconds, Business every 5 seconds, and Enterprise every 1 second. You can run different monitors at different intervals on the same account.
What can HTTP/API checks assert on?
Status code, a substring or pattern in the response body, a specific JSON field value, response headers, and a maximum response time. Assertions stack, so the check only passes when every condition you've defined is met — catching degraded responses that still return a 200.
How do heartbeat (cron) checks work?
Instead of PingInsight calling your service, your scheduled job calls PingInsight with a simple HTTP request when it finishes successfully. If the expected ping doesn't arrive on schedule, PingInsight raises an alert — ideal for backups, cron jobs, and ETL pipelines that have no public endpoint to poll.
Keep exploring

Explore more

Start monitoring in under a minute

Free forever, no credit card. Upgrade when you need finer intervals.