Monitors fire alerts for services that were actually up. False positives drain attention and erode trust in monitoring. This guide covers root causes and mitigation strategies.
What counts as a false downtime • Too-aggressive timeouts • Zero retries • Brief network blips • Rate limiting by target service • Temporary SSL renewal hiccups • Strategy to reduce false positives • FAQ
A false downtime is an alert where the monitored service was actually working correctly but a monitor briefly marked it down. Common in:
Zero false positives are impossible on the open internet. Goal is to keep false-positive rate below 1–2% so alerts remain credible.
Default HTTP timeout is 48 seconds. For slow services (WordPress on shared hosting, large database-backed pages), 48s may be tight.
Fix: increase Request Timeout to 60–90 seconds. Better to wait for a slow response than alert on transient slowness.
Default Retries = 0 means any single failure triggers alert. Brief network blips cascade to alerts.
Fix: set Retries to 2–3 for production services. Monitor must fail 3–4 consecutive times before alert. Catches real outages, ignores transient glitches.
Your Uptime Kuma instance is on SmartXHosting UK infrastructure. Brief packet loss or routing blips can cause single-check failures. Real outages persist; blips don’t.
Retries (above) handle this.
If your service rate-limits automated traffic, and your Uptime Kuma checks every 20–60 seconds, the service may occasionally throttle the monitor — returning 429 Too Many Requests.
Fix: reduce check frequency (60s instead of 20s), or whitelist Uptime Kuma’s source IP in the target service’s WAF/rate-limiter.
SSL certificates renewing automatically sometimes cause a 1-2 minute window where the cert is being swapped. Uptime Kuma may catch this window and flag SSL errors.
Fix: Retries = 2–3 catches the 1-2 minute window. On SmartXHosting, Let’s Encrypt renewal happens during low-traffic hours (03:00–05:00 UK) to minimise impact.
Tuned monitoring, credible alerts
SmartXHosting Uptime Kuma runs on UK infrastructure with low latency to UK ISPs — fewer false positives than cross-Atlantic SaaS monitors.
View Uptime Kuma HostingQ: Getting 5 false positives per week. Is that normal?
A: Depends on check frequency and service reliability. 1–2 per week for critical monitors with proper retries is typical. 5+ suggests retries too low or a genuinely flaky service.
Q: Should I set Retries higher than 3?
A: Beyond 3, you’re masking real issues. 3 strikes a balance between false-positive reduction and timely alert.
Q: Can I silence alerts temporarily during known issues?
A: Yes — create a maintenance window covering the affected monitors for the known issue duration.
Q: How do I track false-positive rate?
A: Export executions, classify real vs false. Track monthly. Monitor tuning pays off when rate drops below 2%.
Q: False positives at 03:00 UK time specifically?
A: Likely SSL renewal window. Use Retries to absorb.