Setting Up Uptime Monitoring: Uptime Kuma, Pingdom, UptimeRobot
You've just rolled out a release, and suddenly — the first complaints from customers: 'site not loading.' The team learns about the outage not from a monitoring system, but from the support chat. We've seen this dozens of times: the simplest and most reliable fix is to set up uptime monitoring. You don't need complex observability — just check HTTP response from /health or /healthz every 30–60 seconds. If the response is not 200 three times in a row — alert. Without this basic layer, any outage becomes a surprise. Mean time to detection (MTTD) drops from tens of minutes to seconds, and the cost savings from an hour of downtime can reach thousands of dollars. Want that reliability? Contact us — we'll choose the right tool for your infrastructure.
Which monitoring tool to choose: Uptime Kuma, Pingdom, or UptimeRobot?
The choice depends on whether you're willing to manage a server or prefer SaaS. Let's compare popular solutions.
| Instrument | Type | Locations | Alerts | When to pick |
|---|---|---|---|---|
| Uptime Kuma | Self-hosted | Your own node | Email, Slack, Telegram, PagerDuty | You have a Kubernetes cluster, don't want to pay subscription |
| UptimeRobot | SaaS | 160+ locations | Email, Slack, Webhook | Quick start, free tier with 50 monitors |
| Pingdom | SaaS | 100+ locations | Rich integrations, RUM | You need detailed reports and real-user monitoring |
| Better Uptime | SaaS | 30+ locations | On-call, status page | You want all-in-one: monitoring + incident management |
Uptime Kuma is our favorite for Kubernetes. It costs 5 times less than Pingdom for similar features, and deployment takes 5 minutes:
helm repo add uptime-kuma https://helm.irsigler.cloud
helm install uptime-kuma uptime-kuma/uptime-kuma \
--set ingress.enabled=true \
--set ingress.hosts[0].host=uptime.example.com \
--namespace monitoring
For the SaaS option, registration takes 2 minutes. The decision often comes down to budget and desire to control data privacy.
How to set up Uptime Kuma in 5 minutes
- Install the Helm chart as shown above.
- Configure Ingress and TLS — certificate from Let's Encrypt via cert-manager.
- Add the first monitor: HTTP check on
/healthwith a 30-second interval. - Set up notifications: Telegram or Slack.
- Check the status page — dashboard is ready.
Additional: Monitor SSH and database ports
For internal infrastructure, add TCP checks on ports 22, 3306, 5432. This ensures the server is reachable even if the web app is down.What to monitor and how often: typical parameters table
The minimal set of checks for a typical web project and recommended intervals.
| Check type | Example endpoint | Interval | Timeout | Retry count |
|---|---|---|---|---|
| HTTP / HTTPS | /health |
30–60 s | 15–30 s | 2 |
| Ping | Server IP | 60 s | 10 s | 3 |
| TCP port | :443 |
60 s | 15 s | 2 |
| SSL certificate | — | every 6 hours | — | — |
| Synthetic (browser) | checkout flow | 5–10 min | 30 s | 1 |
For the main page and API health endpoint, an HTTP check once per minute is enough. If the service depends on an external API (e.g., payment gateway), monitor that too to distinguish your own failures from partner issues.
Why false alarms happen and how to avoid them?
The most common pain in uptime monitoring is false positives. A single lost packet can trigger an alert at 3 AM. We use three rules:
- Retry before alert: at least 2–3 consecutive failures. In Uptime Kuma, this is Heartbeat Retry.
- Timeout: 10–30 seconds depending on the service. A 5-second timeout guarantees false alerts under any load.
- Alert cooldown: repeat notification no more than once per hour for a sustained outage.
This setup should be planned in advance — it saves chat noise and preserves the on-call engineer's sanity. According to Uptime Institute, 30% of alerts are false without proper retry and cooldown configuration.
SSL certificates and domains: don't let HTTPS fall
Monitoring certificate expiry is a standard but often forgotten practice. We set alerts 30 and 7 days before expiration. In Uptime Kuma, this is built-in — just add an SSL Certificate check on the domain. If you don't monitor it, a certificate can expire over a weekend, HTTPS stops working, and you learn about it from customers. Order monitoring setup — we'll anticipate all such scenarios.
What is synthetic monitoring and why do you need it?
Synthetic checks simulate user actions (login, checkout) and uncover problems invisible to simple HTTP checks. For example, a page returns 200 but the cart doesn't update. Setting up such scenarios is the next level after basic uptime. We include synthetic monitoring for critical business paths. For each scenario, we write a script in Puppeteer or Playwright, run it every 5–10 minutes from multiple locations. The alert triggers on errors or response time breaches. One such check replaces dozens of manual QA checks.
What you get as a result: full package
After configuring monitoring, you receive:
- Dashboard of all critical service status (self-hosted or cloud)
- Automatic alerts to your messenger / PagerDuty without noise
- SSL certificate and domain name monitoring
- Documentation: runbook for each monitor, threshold descriptions, and alert actions
- Improvement recommendations: what checks to add, how to set up synthetic monitoring for complex scenarios (login, checkout)
We also grant system access and train on-call engineers to respond to alerts. Uptime Kuma deployed on Kubernetes saves up to 90% on SaaS subscriptions with similar functionality. Get a consultation — we'll prepare a proposal for your infrastructure.
Timeline and budget
Basic monitoring setup for 5–10 endpoints on a SaaS tool takes from 4 hours. If you choose self-hosted Uptime Kuma with integration into existing notification channels and monitoring of 20+ endpoints — up to 2 days. Cost is calculated individually, but typical savings compared to Pingdom are $30–60/month. With over 5 years of experience and 150+ monitoring setups, we bring proven expertise. Contact us — we'll prepare a proposal for your infrastructure.