An UptimeRobot alternative that explains the outage

The free plan question

For years the default advice was "just use UptimeRobot's free plan." Since late 2024 that plan is limited to personal and non-commercial use; business websites, revenue-generating apps and anything tied to a for-profit company need a paid plan. That is a reasonable business decision on their side, but it changes the comparison for startups and indie products.

UpButler's Free plan is smaller (10 monitors instead of 50, both every 5 minutes) but it has no commercial restriction, and it includes the things a product needs once customers notice outages: a public status page, email, webhook, Slack, Discord and RSS subscribers, and 10 AI incident reports a month. Every new workspace also starts with 14 days of Pro, no card, so you can try 30-second checks and several regions before deciding.

Fewer alerts, better ones

A single timed-out request is not an outage. When an UpButler check fails, it is re-checked about 15 seconds later, and the monitor only flips to down after two consecutive failures (configurable per monitor). If three services on the same status page fail within 30 minutes, you get one incident, not three. Reminders follow at 30 minutes, 2 hours and 8 hours if it is still down, and the recovery closes the incident on its own.

With more than one region (2 on Starter, 3 on Pro, all four EU locations on Business), each round is checked from every region and a monitor only goes down when a majority of the regions that answered agree. A network problem between one location and your server shows up per region but does not wake you.

Each incident also carries an AI report: likely causes based on the actual check results (status codes, timings, TLS and DNS details, response excerpts), suggested next steps, and a public summary written for customers. On recovery you get a post-incident summary. UptimeRobot tells you that something is down; UpButler tries to tell you why and what to say about it.

More than "is it up?"

Beyond HTTP, keyword and port checks you can assert on JSON fields and headers, mark a monitor degraded when latency crosses a threshold, and get warned before a TLS certificate expires. Cron jobs report in with a single curl:

# Cron job: ping on success, or report a failure explicitly
0 * * * * /usr/local/bin/backup.sh && curl -fsS https://upbutler.com/hb/<token> || curl -fsS https://upbutler.com/hb/<token>/fail

Manifest monitors read one JSON health endpoint and turn every key into its own status page component, which is handy for a backend that already knows the health of its dependencies. Pro adds scripted multi-step API checks; Business adds real-browser checks with Playwright.

Monitoring your agents can set up

UptimeRobot now has an official MCP server, so this is no longer a one-sided story. The difference is in the shape of the API. In UpButler a single call creates a monitor and the status page component that follows it (services_add over MCP, POST /api/v1/services over REST), batch pushes update many components at once, and an agent with no account can bootstrap a workspace and hand a claim link to its human. See the agent quickstart.

Where UptimeRobot is ahead

Volume and reach. 50 free monitors, 15-second intervals on its Scale plan, hundreds of monitors per account, ICMP ping, SMS and voice-call alerts, and a long list of integrations. It also has a decade of reliability behind it. If you need those, it is a good product and you should keep it. Our check locations are all in the EU; if you need checks from other continents, UptimeRobot covers more of the world.

Moving your monitors over

UpButler imports straight from UptimeRobot. In the dashboard open Settings → Import, choose UptimeRobot and paste a read-only API key from your UptimeRobot settings. You get a dry run listing every monitor, alert contact and status page with what will happen to it; nothing is written until you confirm. The key is used for that import only and never stored, and running it again only adds what is new.

# Dry run: what would be created, what already exists, what is skipped and why
curl -X POST https://upbutler.com/api/v1/import/preview \
  -H "Authorization: Bearer $UPBUTLER_KEY" -H "Content-Type: application/json" \
  -d '{"source":"uptimerobot","apiKey":"<UptimeRobot read-only API key>"}'

# Run it (background job; poll GET /api/v1/import/jobs/<id>)
curl -X POST https://upbutler.com/api/v1/import \
  -H "Authorization: Bearer $UPBUTLER_KEY" -H "Content-Type: application/json" \
  -d '{"source":"uptimerobot","apiKey":"<UptimeRobot read-only API key>"}'

1. HTTP(s) and keyword monitors keep their URL, method, headers, body, timeout and keyword rule (alert when present or when missing), and their interval, raised to your plan's minimum where needed. Paused monitors stay paused.
2. Port monitors become TCP checks and heartbeat monitors become heartbeats with the same period. Point each cron job at its new ping URL afterwards.
3. Alert contacts of type email, webhook, Slack and Discord become alert channels, linked to the same monitors. Other contact types (SMS, voice and so on) are skipped.
4. Status pages come over with their monitors as components, and the preview reminds you of any custom domain to add in page settings once bring-your-own domains are live (from Starter).
5. Ping (ICMP) monitors are skipped; add a TCP check against an open port instead.

Keep both running for a few days and compare. Once you trust the new alerts, pause the old monitors. An agent can run the same import over the MCP server.