Know when your project stops responding.

Plan uptime checks, notification channels and status pages. Keep the monitoring data persistent and the administrator interface protected.

Start with one meaningful check

Choose an HTTP(s) endpoint you own, the expected status code and a reasonable interval. A homepage returning 200 does not prove every database query works. A dedicated health route can make the check more useful.

Protect the initial setup

The local example binds port 3001 to localhost. Create the administrator account before exposing the instance, enable 2FA and configure HTTPS in your real deployment. No public Kuma dashboard is created by Botkeep today.

History belongs on persistent storage

Keep /app/data on supported local persistent storage, not NFS. Check retention and disk growth, and test backup restoration. Notification credentials are sensitive; they do not belong in a downloadable planning worksheet.

Avoid a shared point of failure

A monitor on the same failed node cannot reliably alert you about that node. Use independent monitoring for critical services. More frequent checks and more monitors increase resource use; they are not unlimited.

Your first monitoring worksheet

Type: HTTP(s)
Target: an endpoint you control
Expected status: 200–299
Interval: 60 seconds (example)
Notification: send a test before relying on it

The worksheet is not an import format. Configure and test the monitor in the real Kuma UI.

Plan your resources

Try a concrete starting point

Services

Uptime Kuma

A local monitoring setup with persistent data and a worksheet for your first check.

5 files · instructions includedExplore project

Enabled profiles can be deployed from the panel. Configure addresses and HTTPS in Domains; a custom domain requires DNS verification. No performance or availability guarantee is implied.