English
Uptime Kuma Hosting
Monitor services with status checks, notifications, history, and public status pages.
No setup fees-
One click deploy -
1 GB RAM Memory needed -
15 GB Disk Space Needed -
From 2 € Price
Official links
Uptime Kuma’s official links and original website
Uptime Kuma Website
More
Tech
- Docker image
- louislam/uptime-kuma:2
- Default port
- 3001
How Uptime Kuma works
Uptime Kuma schedules monitors for supported protocols and records each result over time. HTTP and keyword checks can test a web endpoint, TCP monitors verify that a port accepts connections, ping and DNS cover basic reachability, push monitors receive an external heartbeat, and other monitor types cover documented services. Dashboards display current status, history, response time, certificates, incidents, and maintenance periods.
Every result reflects the network position and permissions of the monitoring server. A service reachable from another country or private network may look different from the hosted node, and one location cannot prove global availability. The catalogue does not mount a Docker socket, so Docker-host monitoring is not part of the default package. Private targets must be reachable through an authorised network path.
Key Uptime Kuma features
Notification integrations can forward state changes to many supported providers, while status pages publish selected monitors for users or customers. Those channels require external accounts, webhooks, bots, telephone or messaging providers, and recipient configuration. Application email is disabled, so SMTP-based Uptime Kuma notifications cannot send mail from the hosted installation.
Maintenance windows can suppress expected alerts, and certificate information helps identify approaching expiry where the monitor can inspect TLS. Uptime Kuma is an availability checker rather than a full observability platform: it does not collect every application trace, correlate distributed incidents, provide on-call staffing, or repair a failed service.
Uptime Kuma vs UptimeRobot
Uptime Kuma and UptimeRobot both monitor endpoints, send alerts, and publish status pages. Uptime Kuma is a self-hosted application whose checks originate from the deployed server. UptimeRobot is a provider-managed service with hosted monitoring locations, account plans, alert channels, and maintained public status-page infrastructure.
UptimeRobot may suit teams that want monitoring operated outside their own hosting environment and do not want to maintain the monitor server. Uptime Kuma is more attractive when the organisation wants direct control of checks and history, while accepting the limits of the hosted node’s network viewpoint and external notification dependencies.
Who uses Uptime Kuma
Administrators watch websites, APIs, routers, DNS records, and supported ports. Developers track test endpoints, while small service teams publish a focused status page and use maintenance windows during planned work. Push monitors also let scheduled jobs report their own successful completion.
Uptime Kuma is less suitable as the sole control for regulated uptime reporting, security monitoring, multi-region proof, log analysis, distributed tracing, or managed incident response. Critical services should use independent monitoring paths and tested escalation procedures.
Self-hosting Uptime Kuma: requirements and cost
Uptime Kuma resource use grows with monitor count, check interval, retained history, response processing, status-page traffic, notification activity, and concurrent dashboard users. The catalogue provisions no PostgreSQL or MariaDB service and persists /app/data. The software itself is free to run; very frequent checks and long history across many monitors require more resources than a small endpoint list.
On AvaHost, Uptime Kuma uses Plan 1 at €2. The hosted Uptime Kuma package includes one-click deployment, a custom domain with automated HTTPS, automatic application updates, and scheduled backups. SMTP email, external alert-provider accounts, bots, webhooks, telephone delivery, multi-region probes, private-network connectivity, Docker socket access, incident staff, repair actions, and compliance reporting are not included. Test notifications through each authorised external channel and maintain an independent path for critical alerts.
F.A.Q
Uptime Kuma starts at €2 on Plan 1. A modest set of monitors with sensible intervals and ordinary history can begin on the entry plan. Monitor count, check frequency, retained results, response processing, status-page visitors, notification volume, and concurrent dashboard users determine when more capacity is appropriate.
Checks originate from the hosted Uptime Kuma server and reflect its network route, DNS view, and permissions. One node cannot demonstrate availability from every region or private network. For critical services, compare results with independent probes and user reports, and make sure private targets are reachable only through an authorised path.
Application email is disabled, so SMTP notifications from Uptime Kuma cannot deliver mail through the hosted package. Other supported notification methods may work when you provide the required external account, webhook, bot, or provider credentials. Configure each channel separately, send test alerts, and maintain an independent escalation route for incidents that matter.
A custom domain can point to Uptime Kuma, and automated HTTPS protects dashboard and status-page traffic. Publish only the monitors and incident detail intended for external readers. The catalogue does not provide multi-region probes, Docker socket access, private-network tunnels, provider accounts, or managed incident response, so those elements need separate design.