Diagnose Disappearing Monitors Before Rebuilding the Database

Preserve evidence before refreshing everything

Record the time, installed version, deployment image, database backend, and actions that caused the list to disappear. Capture a screenshot and relevant browser request or socket errors before clearing site data. Avoid sharing cookies, authorization headers, notification secrets, or private monitored URLs in an issue report.

Try another authenticated session against the same instance. Check whether status pages and existing notifications continue to show current activity. An empty list in one browser while the service continues checking targets suggests a loading or session problem; it does not by itself prove database deletion.

Separate interface, transport, and persistence

Review the Uptime Kuma reverse-proxy requirements (opens in a new tab) when a proxy fronts its UI. Inspect matching application and proxy errors around the event. The troubleshooting guide (opens in a new tab) is a starting point for release-specific diagnostics.

Also verify that the process mounted the expected persistent volume and connected to the intended database. A new empty volume after a deployment change can look like lost monitors while the old data still exists elsewhere. Record paths and volume identity before moving or deleting anything.

Make a consistent recovery copy

Back up application configuration and the actual database using the supported method for that backend. For SQLite, an online backup API (opens in a new tab) can create a consistent snapshot. If stopping the application to copy its data directory, ensure all writers are stopped cleanly and capture the complete required data, not one guessed file from a live volume.

For an external database, follow its backup procedure and include application secrets needed to decrypt stored configuration. Keep the copy restricted because monitor and notification configuration can contain credentials.

Restore to a separate instance with notification delivery and outbound integrations disabled. Verify monitor definitions, status-page membership, and the expected historical scope. This is a recovery test; it is not permission to point the clone at the production database.

Measure before repairing

Inspect disk capacity, I/O latency, database size, memory pressure, and connection failures. Compare the time the UI fails with any cleanup or backup task. A migration to different hardware may improve a symptom without proving that processor architecture caused it.

Try a supported retention change, version upgrade, or storage adjustment on the clone one at a time. Do not delete heartbeat tables or run a schema-changing repair copied from a different release. Preserve the original backup and document the changed variable.

When applying the justified fix, verify repeated navigation, monitor editing, status-page loading, and fresh check execution. Finally trigger a controlled notification so recovering the interface does not leave a broken alert path undiscovered.