By LogicSystemIQ | 2026-06-11 | 8 min read
The worst way to find out your website is down is a text from a customer. The second worst way is checking your inbox Monday morning and realizing your contact form has been silently failing since Thursday, and three leads went nowhere.
Most small businesses have zero monitoring. Not because it is hard, but because the tools that show up first on Google are priced for engineering teams, and nobody has time to compare twelve vendors. So here is the setup we use, with real configuration you can copy.
Uptime Kuma is a free, self-hosted uptime monitoring tool that runs in Docker. It checks websites, APIs, webhooks, and scheduled jobs on intervals you choose, then alerts you by email or chat the moment something breaks. A small business can monitor 30+ endpoints for $0 per month.
Why paid monitoring is the wrong size for most small businesses
Paid uptime tools are good products. They are just built and priced for someone else.
| Tool | Free tier | Paid starts around | The catch |
|---|---|---|---|
| UptimeRobot | 50 monitors, 5-min checks | $8/mo | 5-minute gaps on free, SMS costs extra |
| Pingdom | None | $10/mo | Per-monitor pricing climbs fast |
| Better Stack | 10 monitors | $25/mo | Excellent, but priced for funded startups |
| StatusCake | 10 monitors, 5-min checks | $20/mo | Limited features until you pay |
| Uptime Kuma | Unlimited monitors | $0 | You host it yourself |
The pattern: free tiers check every 5 minutes and cap how many things you can watch. That sounds fine until you list what a real small business actually depends on. Our own list came out to more than 30 endpoints: marketing sites, client-facing dashboards, a CRM, more than 15 automation webhooks, a mail server, a database provider, cloud storage, and a payment provider.
At per-monitor SaaS pricing, watching all of that costs real money every month, forever. Self-hosted, it costs the electricity your computer was already using.
What Uptime Kuma actually is
Uptime Kuma is an open-source monitoring tool with tens of thousands of GitHub stars and active development since 2021. Think of it as a self-hosted UptimeRobot with a clean web dashboard.
It supports the monitor types that matter:
- HTTP(s) checks with keyword matching, so you catch the “page loads but shows an error” failures, not just hard downtime
- POST requests with JSON bodies, which is how you check webhooks and APIs
- TCP port checks for mail servers and databases
- DNS resolution checks
- Ping for raw host reachability
- Push monitors (heartbeats) for cron jobs that should check in on schedule
Alerts go out through more than 90 notification channels: email, Telegram, Slack, Discord, webhook, and basically anything else you use.
The setup: Docker, about 10 minutes
If you already run Docker anywhere (a spare PC, a $5 VPS, the same server as your apps), the whole install is one compose file:
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
restart: unless-stopped
ports:
- "127.0.0.1:3001:3001"
volumes:
- ./data:/app/data
Run docker compose up -d, open http://localhost:3001, create your admin account, and you are looking at the dashboard. The ./data bind mount means your monitor history survives upgrades, and backing up the whole system is just zipping one folder.
If you want a home-server angle on this, we wrote up how we run 27 Docker containers on 12GB of RAM. Uptime Kuma is one of the lightest things on that box.
What to monitor: the four groups
The mistake most people make is monitoring the homepage and calling it done. The homepage is the thing that breaks least. Here is how we group monitors, in order of how much pain each one prevents.
1. Public websites and apps
HTTP checks every 60 seconds, with keyword matching. Do not just check for HTTP 200. A WordPress site with a database error returns 200 with an error page. Set the monitor to require a word that only appears when the page actually renders, like your company name in the footer.
2. Webhooks and form endpoints
This is the group nobody monitors and everybody should. If your contact form posts to an automation platform like n8n, Zapier, or Make, that endpoint can die silently while your website looks perfectly healthy. Lost leads, no error message.
Uptime Kuma can send a real POST with a JSON body, for example {"ping": true}, to each webhook every few minutes and alert if it stops answering. We watch over 15 automation webhooks this way.
3. Third-party dependencies
Your stack depends on services you do not control: your database provider, payment processor, mail server, cloud storage. Monitor them anyway, for two reasons. First, you find out before your customers do. Second, when something breaks, you immediately know whether it is your code or their outage, which cuts debugging time in half.
Two tricks worth knowing:
- An authenticated API with no public health page can be monitored by expecting an error code. We point a monitor at a payment API and expect HTTP 401. If we get 401, the API is up. If the monitor times out, it is down.
- A private storage bucket should return 403 to the public. So expect 403. If it ever returns 200, you have a worse problem than downtime.
4. Scheduled jobs (the silent killers)
Backups, nightly cleanup jobs, report generators. When a cron job dies, nothing goes down. It just quietly stops happening, and you find out weeks later when you need the backup that was not taken.
Push monitors flip the direction: the job calls a unique Uptime Kuma URL when it finishes (one curl line at the end of the script), and Uptime Kuma alerts you if the call does not arrive on schedule. For a nightly job, set the window to 25 hours and you will know by breakfast.
| Group | Example | Check type | Interval |
|---|---|---|---|
| Websites | Marketing site, client portal | HTTP + keyword | 60s |
| Webhooks | Contact form endpoint | POST + JSON body | 5 min |
| Third-party | Database, payments, SMTP | HTTP / TCP port | 5-10 min |
| Scheduled jobs | Nightly backup | Push (heartbeat) | 25h window |
Alerts you will actually see
Monitoring that alerts a dashboard nobody looks at is decoration. Wire notifications to a channel you already check.
Email is the simplest start: Uptime Kuma talks to any SMTP server, so you can send alerts through a mailbox you already pay for. Add the SMTP credentials under Settings, Notifications, hit Test, and confirm the message arrives.
Then do the step everyone skips: break something on purpose. Point one monitor at a wrong port, wait two checks, and confirm the alert email actually lands. Then fix the monitor and confirm the recovery email arrives too. A fire drill takes five minutes and is the only way to know the chain works end to end.
Status pages: one for the team, one for customers
Uptime Kuma includes status pages out of the box. We recommend two:
- Internal, password-protected, showing every monitor. This is your operations view.
- Public, showing only customer-facing services. When someone asks “is it down for everyone or just me,” you send a link instead of a paragraph.
What it costs to run
On our setup, Uptime Kuma idles around 150-200MB of RAM with negligible CPU. It runs comfortably on a workstation, a Raspberry Pi, or the smallest VPS any provider sells.
Three operational caveats from experience:
- Stop the host from sleeping. On a Windows machine, set Sleep to Never while plugged in, or your monitoring naps with it.
- Start Docker on login, so a reboot does not silently end your coverage.
- Watch the watcher. If the machine running Uptime Kuma dies, who tells you? Point one free external check (UptimeRobot’s free tier is fine for this) at your Uptime Kuma instance itself. Monitoring your monitoring sounds paranoid right up until the day it pays for itself.
FAQ
Is Uptime Kuma really free?
Yes. It is MIT-licensed open source. There is no paid tier, no monitor limit, and no feature gate. Your only costs are the hardware it runs on and the minutes you spend setting it up.
Where should I host it?
Anywhere that is not the same machine as the things you are monitoring, ideally. A $5/month VPS or a spare office PC both work. Hosting it at a different provider than your website means one outage cannot take down both the site and the thing that tells you the site is down.
Can it monitor things behind a firewall?
Yes, if Uptime Kuma runs inside the same network. That is one of the advantages of self-hosting: it can check internal services, local NAS boxes, and office equipment that cloud monitors cannot reach.
What happens if the machine running Uptime Kuma goes down?
Nothing, silently, which is exactly the problem. Use the external watchdog trick above: one free cloud check pointed at your Uptime Kuma URL closes the loop.
How is this different from what a managed IT provider gives me?
The tool is the easy half. Knowing what to monitor, tuning the alerts so they do not become noise you ignore, and actually responding at 2 AM is the hard half. If you want the setup without owning the pager, that is literally what we do.
The bottom line
You do not need a budget line to know when your business breaks online. One Docker container, an afternoon of adding monitors, a five-minute fire drill, and you will never again learn about an outage from a customer.
If you would rather have someone build the whole thing for you, monitors, alerts, status page, and response included, we set this up as part of our managed IT services and our cloud infrastructure work. Book a free consultation and we will map what your business should be watching.
LogicSystemIQ is an IT managed services and SaaS studio based in Peabody, Massachusetts. We build DaycarePro (daycarepro.cloud), a trilingual SaaS for licensed home daycare providers. Reach us at (978) 815-1047 or Support@LogicSystemiq.com.