Uptimy Agent · open source

Uptime monitoring that runs inside your cluster

Most monitors check from the outside, so they miss what breaks most: the database behind the API, a worker on a private network, a CronJob that quietly stopped. Uptimy Agent runs next to your services and checks them from there. One small binary with a UI and a status page, Apache-2.0.

Get it on GitHub See a live status page

9 MB image · 8 MiB of memory idle · Docker, Kubernetes and Railway

What it checks

Websites and APIs

HTTP(S) with status codes and keywords, TCP, ping, DNS and TLS certificate expiry.

Databases

Postgres, MySQL and Redis with a real login and query. Catch a failover with SELECT pg_is_in_recovery().

Kubernetes

Services, Ingresses, Deployments and CronJobs, found from a label and checked from inside the cluster.

Cron jobs and workers

Heartbeats on an interval or a cron schedule in any time zone, with missed and failed runs, exit codes and durations.

Private services

postgres.default.svc, api.railway.internal and anything else the agent can reach, without exposing it.

Alerts and a status page

Email, Slack, Teams, Discord, Telegram, PagerDuty, webhooks and 30+ more, plus a public status page with your logo.

On Kubernetes, label it and it's monitored

Put one label in your manifests and every app is monitored the moment it's deployed. A Service is checked on its pods' readinessProbe path, a Deployment on its ready replicas, and a CronJob gets a heartbeat whose runs are read from its Jobs, failures and exit codes included. The agent only reads the cluster.

Terminal

helm install uptimy-agent oci://ghcr.io/uptimy/charts/uptimy-agent -n monitoring --create-namespace
kubectl -n shop label service checkout upti.my/monitor=true
kubectl -n shop label cronjob backup upti.my/monitor=true

Kubernetes guide: from install to the first alert →

Runs anywhere

Docker

docker run -d --name uptimy-agent -p 8080:8080 \
  -v uptimy-agent:/data ghcr.io/uptimy/agent

Railway

One click adds the agent to your project, with a volume and a generated password. It reaches your *.railway.internal services and databases from there.

Switching from Uptime Kuma

Upload Kuma's kuma.db and see what each monitor and notification becomes before anything is imported. HTTP, keyword, TCP, ping, DNS, TLS, database and push monitors carry over, with notifications and status page membership.

Uptimy Agent vs Uptime Kuma: features and measured resource use →

When the whole cluster goes down

Nothing inside a cluster can tell you the cluster is gone. Connect the agent to Uptimy in one click and Uptimy alerts you from outside when it stops checking in. Its alerts can also open incidents in Uptimy, which page on-call and run workflows. The agent stays free either way.

Start free with Uptimy →

Frequently Asked Questions

Yes. It's open source under Apache-2.0 and complete on its own: monitors, alerts, a status page and multiple users, with no limits and no account. Connecting it to Uptimy is optional.

No. It runs anywhere Docker runs, as a single binary, or on Railway. Inside a cluster it adds Kubernetes checks and discovery from labels.

Two things a self-hosted monitor can't do alone: Uptimy alerts you from outside when the agent, its server or the whole cluster stops checking in, and the agent's alerts can open incidents in Uptimy that page on-call and run workflows.

It's built to run next to your services rather than as a standalone dashboard: monitors can come from Kubernetes labels or YAML, CronJobs are tracked without pings, and it uses a fraction of the memory. Kuma has far more monitor types and notification services built in. The comparison page goes through both sides.

23:00 · goodnight

All systems operational

Watch what your users can't see.

Uptimy Agent is open source and runs in a minute. Give it a label, and it tells you before your customers do.

Get it on GitHub See a live status page