15-Second Uptime Checks Without the Performance Tax
Most uptime tools treat check interval as a pricing lever: five minutes free, one minute on paid tiers, anything faster locked behind enterprise. The reason is not technical — a check is a sub-second HTTP request. It is that their architecture makes every check expensive. Here is why 15-second intervals are cheap when the system is built for it, and what the real tradeoffs are.
The math that makes interval matter
Your mean time to detect (MTTD) is bounded below by the check interval. With 5-minute checks, a failure can sit undetected for up to five minutes — plus retry and confirmation time on top. With 15-second checks, the same failure is confirmed in under a minute including retries.
For context on what those minutes cost: a checkout outage at moderate traffic is dozens of lost orders. An API outage during a client's batch job is a failed run they will blame on your reliability. The difference between "we knew in 30 seconds" and "customers told us after 8 minutes" is the difference between an incident and an embarrassing incident report.
Fast intervals also matter for flapping detection. A service that drops for 40 seconds every few minutes looks perfectly healthy to a 5-minute probe — the dips fall between checks. A 15-second interval sees the pattern.
Why fast checks are "expensive" elsewhere
The honest reason incumbents gate intervals: their scheduler architecture. If every check is a serverless invocation or a queued job with heavy per-check overhead, quadrupling check frequency quadruples infrastructure cost. 15-second checks across thousands of monitors genuinely hurt — for them.
The check itself is trivial. An HTTP probe is a TCP handshake, a TLS negotiation, a request, a response — typically under 500ms of actual work, and the response time data is the product. The cost is in orchestration: scheduling, distributing, collecting and storing results. Build that layer on dedicated nodes with a fast queue and the per-check cost drops to near zero.
How Uptriva does it
The pinger fleet runs on dedicated nodes, not serverless functions. Check types that functions cannot do — ICMP ping needing raw sockets, UDP game-server queries, DNSBL lookups needing clean IP reputation — work natively. KeyDB-backed queues distribute work to pingers in near-real-time; results flow back through a pipeline designed for high-frequency writes.
At 15 seconds the per-monitor math stays small: 5,760 checks per day, each a fraction of a second of work. The scheduler handles thousands of monitors without the interval becoming a bottleneck — because the interval was a design input, not a billing tier afterthought.
The real tradeoffs (they exist, just not where you think)
Honest list of what faster checks actually cost you:
- Notification tuning — at 15s, a single flaky check can flap. Confirm failures across multiple checks before alerting; a good setup requires 2-3 consecutive failures, which still detects real outages in under a minute.
- Target load — 5,760 requests/day per monitored endpoint. Trivial for production services, worth noting for fragile legacy endpoints.
- Data volume — more results means more storage and more latency datapoints. That is a feature for percentile accuracy, but it is real volume.
What it should not cost: a higher plan tier. Interval is a technical parameter, not a premium feature.
When you do not need 15 seconds
Be honest with yourself: a personal blog, a staging environment, a cron-driven batch endpoint — 60 seconds or even 5 minutes is fine. Fast intervals earn their keep on revenue paths, customer-facing APIs and anything with an SLA attached. The point is having the option where it matters, not paying for it where it does not.
Uptriva supports check intervals down to 15 seconds across 23 check types — HTTP, TCP, DNS, ping, keyword and more — on dedicated probe nodes built for high-frequency work. See how the pinger network is built and the monitor docs.