Diagnose Timeouts Across Every Uptime Monitor at Once
Sources and verification
- Source dates
- Oldest source check: 12 September 2026.
- Technical verification
- Separate technical verification has not been recorded.
Publication approval and technical verification are recorded separately. Automated link checks establish reachability, not accuracy. A checked example verifies only its stated test cases, not the whole article or your production setup.
In short
When unrelated monitors time out together, inspect their shared checking path before changing every target. Compare the same requests from the monitor network and an independent location. Measure scheduling delay, DNS, database I/O, and container limits. Preserve a consistent backup, change one variable at a time, and verify fresh checks and notification timing after recovery.
Key takeaways
- Low average CPU does not rule out an overloaded monitoring process.
- Compare scheduled check time with actual execution time.
- Preserve the monitoring database before cleanup or upgrades.
Establish whether the targets actually failed
Fifty unrelated websites timing out within the same minute is a clue about shared dependencies, not proof of a monitoring bug. Check one affected service, one endpoint you control outside the network, and one local endpoint. Repeat from the monitoring container's network and from an independent host. Record resolved address, connection time, HTTP result, and observation timestamp.
If the independent host succeeds while the monitor network fails, investigate its DNS, gateway, proxy, firewall, and provider path. If a command inside the same network succeeds while scheduled checks are late, inspect the application and storage. Keep user-facing evidence separate: a checker fault can coexist with a real target outage.
Inspect the delay that a CPU graph hides
Collect a short timeline rather than immediately increasing retries. Capture the deployed image digest or version, database backend, monitor intervals, timeouts, retention, and any recent configuration change. Restrict logs before sharing them because notification URLs and target credentials can be sensitive.
| Evidence | Plausible next investigation |
|---|---|
| Checks start late across unrelated targets | Scheduler queue or runtime stalls |
| Requests start promptly but DNS is slow | Resolver path, retries, or rate limits |
| Database writes stall at the same time | Storage latency, locks, capacity |
| Container is throttled despite an idle host | Container resource limits |
| Dashboard freezes while fresh checks continue | UI or connection path |
Look at peak memory, restarts, disk free space, disk wait, and throttling over the failure window. A host-level average can conceal a short stall or a limit applied only to one container. Follow the project's troubleshooting guidance (opens in a new tab) when collecting diagnostics for the installed release.
Preserve data before changing storage
Record monitor counts and make a recoverable configuration and database backup before retention changes, migration, or cleanup. A plain copy of a changing database file is not automatically consistent. For SQLite, its online backup API (opens in a new tab) provides a supported consistency mechanism; an application-supported backup or a cleanly stopped, complete data-volume copy may be more practical for your deployment. For an external database, use that backend's supported procedure.
Restore the backup into an isolated instance with notification sending disabled. Confirm monitor definitions and status-page configuration are present. This tests the escape route before you depend on it.
Change one bottleneck and remeasure
Try the narrowest justified intervention: correct a resource limit, restore storage headroom, reduce unnecessary history through a supported setting, or upgrade a cloned deployment after reading release notes. Deleting internal tables based on an old forum answer can destroy evidence or break a newer schema.
Keep the independent reference probe running throughout the change. Measure at least several complete check cycles, including intentionally slow targets. Verify that actual start times remain near scheduled times and a fresh test failure reaches the expected receiver. Record what changed and what did not; several simultaneous adjustments cannot establish which one solved the issue. Keep an outside heartbeat for the checker so the next shared failure does not leave the whole dashboard silently stale.
Did this help?
Your answer helps us improve this guide. We save only the page and your choice for 30 days.
No name, email, or incident details are requested.
Sources
Vendor facts change. Each source below shows the date this page last checked it.
- Uptime Kuma troubleshooting — Uptime Kuma. Checked 12 September 2026.
- SQLite online backup API — SQLite. Checked 12 September 2026.
Related
One practical idea, occasionally
The On-Call Brief: short field notes, templates, and operational lessons.
Follow the field guide
Email subscriptions are not open yet. Read new guides in your feed reader — no email address needed.
Subscribe with RSS