Better Stack vs UptimeRobot free tiers (2026): we timed real outage alerts on Better Stack

What we tested and how

Everything below happened on October 1, 2026. Times are Singapore time (SGT, UTC+8), with UTC in brackets where it matters. We used one fresh account per vendor, both on the same Gmail inbox. A Python Playwright script drove a real Google Chrome window at 1440×900. Our method and rules are on How we review.

• Better Stack: we signed up for the Free plan, went through onboarding, and created two HTTP monitors with 3-minute checks. Monitor B was saved at 08:15:38 SGT (00:15:38 UTC). We also created a heartbeat monitor and a status page, and looked at the integrations, team, API token and billing pages. Nothing external was connected, and we never entered a card.
• The outage target is a small Cloudflare Worker on a workers.dev subdomain. It is the same Workers setup we describe in our Cloudflare Pages and Workers free-plan review. Inside four scheduled windows it returns HTTP 503 on /; the rest of the time it returns 200. Every request from Better Stack's bot is logged to Cloudflare D1, timestamped to the millisecond on the Worker's clock. Alert emails are timed by their Gmail receive time, which has 1-second resolution. A separate watcher loaded the public status page and the dashboard about every 60 seconds; it stopped at 02:08 UTC, so it covered W1–W3 but not W4.
• Monitor settings (confirmed via Better Stack's API): check frequency 180 s, confirmation period 0 s ("Immediate start"), recovery period 180 s, regions eu, us, as, au, request timeout 30 s, SSL verification on, email alerts on. These were the form defaults, apart from the 3-minute frequency.
• UptimeRobot: we opened the signup page at 00:40:41 SGT (16:40:41 UTC on Sep 30) and filled the form. Submitting it opened a Cloudflare Turnstile box, "Confirm you are a human.", which did not pass by itself after more than 20 seconds. The same check appeared for the magic-link option and at login. Our rule is that the test agent never solves or bypasses captchas, so we stopped there at 00:44:11 SGT. A person in a normal browser may well pass this check; we did not test that. Every UptimeRobot fact after signup on this page comes from UptimeRobot's own pricing page, terms and help center, and is labelled that way.

Free tiers side by side

How to read the labels: observed means we saw it in our own Better Stack free account on Oct 1, 2026. official means the vendor's pricing page, terms or docs, fetched from Singapore on Oct 1, 2026. not stated means we searched the official pages and found no answer. Prices are in USD as shown from Singapore. UptimeRobot says other regions can see a different currency and different numbers.

Better Stack free: what happened when our site went down

We set the Worker to return 503 in four windows: two long outages, one 90-second blip, and one window that deliberately starts 47 seconds past the minute. All four windows ran on Oct 1, 2026. The table comes from our probe log and the alert emails.

Probe times come from the Worker's clock, to the millisecond. Email times are Gmail receive times, to the second. The status page was checked about once a minute, so its change times are known only to within that minute; it was not checked during W4. The Worker, Gmail and our Mac use three different clocks, so treat differences under a second as noise.

What the probe log shows

• The site is probed far more often than every 3 minutes. While the site was healthy, a probe arrived from some region every 30.3 s (median, across our quiet periods up to 10:32 SGT). The Singapore, Sydney and Europe (Germany) probes each came about every 120 s. The US probe (Ashburn) came less often and less regularly: median gap 240.5 s, longest 365.4 s. Across our quiet periods, the longest gap between any two probes was 74.5 s. This is what we saw on one monitor on one day, not a promise from Better Stack.
• Before alerting, Better Stack re-checks from other regions within seconds. In W1 the first 503 reached us from Sydney. Europe, the US and Singapore followed 3.1, 3.4 and 3.6 s later, and Singapore again at 6.4 s. W2 looked the same: Europe at +2.6 s, Singapore at +3.1 s and +5.8 s. So did W3: Europe +2.6 s, Singapore +2.9 s, the US +3.8 s, Singapore again +6.4 s. In W4 the first 503 came from the US; Sydney, Europe and Singapore followed at +2.8, +3.0 and +3.0 s, and Sydney again at +7.2 s. The email reached Gmail 7.0 s (W1), 6.2 s (W2), 7.0 s (W3) and 7.0 s (W4) after the first failing probe. So "Immediate start" still includes a fast multi-region re-check before the alert. That is our reading of the log; Better Stack does not document how many regions must agree.
• A /favicon.ico request came in alongside the failure. In all four windows, within 0.07 s of the last re-check 503, the same region also asked for /favicon.ico: Singapore in W1–W3, Sydney in W4. That never happened while the site was up. Our guess is that this is a browser loading the error page to take the incident screenshot. Better Stack's docs say screenshots are taken when the failing response has a body, but the request itself is not labelled.
• Recovery takes about 3 minutes, by design. After the first 200, probes came roughly every 1.2–2.5 s (median; 27 in W1, 24 in W2, 36 in W3, 25 in W4) until the incident closed. The resolved email arrived 207.6 s (W1), 187.4 s (W2), 204.1 s (W3) and 188.8 s (W4) after the first successful probe. That matches the default 3-minute recovery period. The dashboard showed the monitor going Down, then "Validating recovery", then Up.
• The "Length" field reports downtime, not the full incident. The W1 resolved email said "Resolved at: 8:58am" but "Length: 15 minutes", which is the length of the outage itself. The 3-minute validation is not counted. The W2 incident showed 12 minutes, again equal to the outage, and the 90-second W3 blip showed 1 minute.

Minute-aligned windows were the lucky case; W4 was not

W1, W2 and W3 started exactly on the minute. Better Stack's probes on our monitor bunched at fixed seconds: most arrived 0–15 s or 30–45 s past the minute. So a probe landed 1.8–5.0 s after each start, close to the best possible timing, and the email followed 8–12 s after the start. W4 started at 47 s past the minute, between the clusters. Its first failing probe came 12.043 s after the start, from the US this time, and the email 19 s after the start. The re-check and email step still took about 7 s; the extra time was waiting for a probe.

W3 was only 90 seconds long, and it still opened an incident and sent both the "started" email (12 s after the start) and the "resolved" email. On our monitor, the frequent probes caught it easily.

Worst case (our reasoning, not a measurement): an outage that starts just after a probe goes unnoticed until the next one. In our log that would mean waiting up to about 75 s (the longest gap we saw), plus the 6–7 s of re-checks and email. Better Stack only promises the configured interval, though. If you plan around its numbers rather than our single day of logs, count on up to 3 minutes plus email delivery before you hear about a problem. At the nominal 3-minute interval, a 90-second blip like W3 could in principle fall entirely between two checks.

What the alert email contains

The "New incident started" email came from [email protected]. The subject is the monitor name plus the start time, for example "outage-target - Oct 1, 2026 at 8:40am GMT+8". The body contains:

• The monitor name, the method and URL that were checked, the resolved IP addresses, the cause ("Status 503"), the start time, and the response body.
• "Acknowledge incident", "View incident" and "I'm unavailable" buttons, plus a note that you can reply to the email to add a comment.
• An upsell line: "P.S. We can also call you next time, just upgrade your account."

The resolved email lands in the same Gmail thread. It adds "Resolved at" (marked automatic) and "Length". One caution: the Acknowledge, View and "I'm unavailable" links each carry a Better Stack magic-link sign-in token. We did not test whether opening one signs in a different browser. Until you know, think twice before forwarding these emails to a shared inbox or a ticket system.

Setup: what signing up was like

Better Stack (completed on Free)

Our automated run took about 7 min 58 s of active time from the signup page to the second saved monitor, plus a 3 min 50 s wait for the first sign-in email. A person clicking by hand would take a different amount of time.

1. Email only. The signup form asks for a work email and sends a magic link (1 field, 1 click). There is no password, and no captcha appeared. You also sign in by magic link every time; the account has no password login.
2. Six onboarding screens. The first requires six fields: first name, last name, company, company size, role, and where you heard about Better Stack. Then come screens for use cases, integrations, a "Where can we call you" phone screen (skip it with "Continue without a test call"), theme and invites.
3. The plan screen pre-selects the paid plan. This is the biggest gotcha. "Pay as you go, $29 per responder license" is ticked when the page loads, and the button reads "Continue with a 60-day money-back guarantee". Click the Free card first, and the button changes to "Continue". After we chose Free, no card form appeared.
4. A sample monitor and a sample incident. The dashboard already contained a google.com monitor we never created, plus an ongoing, unacknowledged "Sample incident" on it. The new status page was also pre-filled with that google.com monitor. Delete both before you rely on your incident count.
5. A request for a backup card on a cardless Free account. The onboarding checklist included "Prevent potential data loss: Your account is at risk of losing data if your next transaction is declined", with an "Enter a credit card" button and a free t-shirt offer. We had no card on file, so there was no transaction to decline. We ignored it.
6. No friendly-name field. The only name field is "Pronounceable monitor name" ("We'll use this name when we call you"), under Advanced settings. Fill it in, or your monitor list shows raw URLs. Monitor A took 3 fields and 3 clicks.
7. API tokens. A global API token returned 401 "Invalid Team API token" on the Uptime API; a team-scoped Uptime token worked. If your script gets a 401, use a team token.

UptimeRobot (signup only)

• It asks for the website first. The signup page opens with one field, "Website to monitor". The Google, GitHub and "Use email" buttons stay disabled until you enter a URL. No name, company or team-size questions were shown.
• Magic link or password. Passwords must have "8 characters, 1 number, a capital letter and 1 special character".
• A Turnstile check on every route in. Submitting the password form, requesting a magic link, and logging in each opened "Confirm you are a human." In our automated Chrome, it had not passed after more than 20 seconds. UptimeRobot sent no email before this check, so we never got as far as an account. From opening the page to our stop took 3 min 30 s, with 3 clicks and 4 fields.

Status pages compared

UptimeRobot Free (official pricing page and terms): 1 status page, "with a unique UptimeRobot URL only". You cannot use your own domain, add a password or subscribers, customize the design, translate it, white-label it or hide it from search engines. A password, white-label and subscribers all need the Team plan ($41/month, or $35/month billed yearly).

Better Stack Free (what our account showed): 1 status page on *.betteruptime.com. Ours loaded logged out (HTTP 200), and in all three test windows our watcher covered (W1–W3) it switched to "Some services are down" within a minute of the outage starting. Logo, light or dark theme, layout, favicon, announcements, the embed iframe and badge, and the history length (7 to 365 days, default 90) are all available. These are marked Billable: removing the "Powered by Better Stack" footer (listed at $250 per page per month, or $208 billed yearly), email and webhook subscribers, a password ($50 per page per month, or $42), IP allowlist, SSO, and custom CSS/JS. "Hide from search engines" and the Google Analytics tag field are disabled. One small trap: after we saved the page, its structure already listed the sample google.com monitor.

Gotchas from the docs

UptimeRobot (from its help center; not tested by us)

• One region, no quorum. Connection failures are retried up to 3 times, 20 s apart; application errors up to 3 times, 10 s apart. Then "a single region's failed (and retried) check is enough to mark the monitor down." SSL errors are not retried at all.
• HEAD by default. HTTP monitors send HEAD and switch to GET only on a retry, and some servers reject HEAD with 403, 404 or 405. Any 2xx or 3xx response counts as up.
• Keyword monitors work the opposite way you might expect: "If the condition selected is true, the monitor status goes to 'down'".
• Downgrading pauses everything. If you are over the new limit, "all of your monitors are paused — not just the monitors above the limit." SSL and domain reminders switched off by a downgrade are not switched back on when you upgrade again.
• Six months without logging in deactivates the account. Logging back in does not resume your monitors automatically.
• Status page subscribers (paid) only get announcements. "Monitor downtime and recovery are never emailed to subscribers automatically."
• Monthly email reports on Free stop after the first 3 months.

Better Stack (docs, plus what we saw)

• Confirmation and recovery are measured in time, not checks. The confirmation period is how long Better Stack waits after a failure before opening an incident. One failed check during the recovery period restarts the recovery timer.
• The timeout must not exceed the check frequency, "as this would cause an error". The default timeout is 30 s.
• Keyword matching is case-insensitive.
• No screenshot on timeouts. Error screenshots are only taken when the failing response has a body.
• Firewall allowlists: Better Stack's probe "IPs will change without prior notice". It suggests allowlisting by User-Agent instead. On our Worker, that was Better Stack Better Uptime Bot followed by a Chrome 130 string.
• Incident grouping can keep a critical incident silent when it is grouped with another one, according to the docs.
• Paid monitor types have no lock icon in the "Create monitor" dropdown next to the button; clicking one just redirects to billing. The form itself does mark them "(upgrade to use)".

Pricing and terms history that matters

If you are choosing a free plan to rely on for years, this history matters more than any single feature. UptimeRobot changed its free-plan terms twice in about 19 months. Better Stack has kept the same free monitor limits (10 monitors, 3-minute checks) since at least 2022, when it was still called Better Uptime, while trimming its free log allowance and now labelling Free as being for personal projects.

What users say

These are user reports, not our findings. We could only collect them from Hacker News and Trustpilot. Reddit, G2, Capterra and TrustRadius blocked our automated requests, so nothing from those sites is included. The sample is small and skewed towards HN, so use it to spot themes, not to score the products.

• Ratings on Trustpilot (Oct 1, 2026): UptimeRobot 4.7 out of 5 from 477 reviews. Better Stack 4.0 from 3 reviews, which is too few to mean much.
• UptimeRobot, 17 reports: 7 are about the 2024 commercial-use ban, and all date from Oct–Nov 2024, before the reversal. One user called it a "fake free plan" (HN, Nov 26, 2024). Another wrote that the change "somehow already took effect on November 1" (HN, Nov 26, 2024). On the positive side, 4 praise alert speed or reliability and 4 praise easy setup; one long-time user wrote "relatively happy" (HN, May 2024). One reports a false positive (HN, Nov 2024). One Trustpilot reviewer says SMS alerts never reached their phones.
• Better Stack, 12 reports: 2 praise heartbeats, for example "I do like BetterStack heartbeats" (HN, Jan 2025). 2 praise reliability and 2 praise easy setup. 4 mention outages or incidents at Better Stack itself, each a single post: status pages showing other customers' pages in Oct 2023 (HN), "Betterstack Is Down" in Dec 2024 (HN), and the Nov 18, 2025 Cloudflare outage. During that outage, one user could not log in to Better Stack or UptimeRobot but kept receiving down alerts (HN). One paid customer reports cutting monitoring and alerting costs by 90% after switching from Datadog and PagerDuty (HN, Jun 2025).

Decision table

Freshping is not on this list because third-party sources say it shut down on March 6, 2026. We could not confirm that on Freshworks' own site, which blocked our requests. For more monitoring and automation write-ups, see Run: monitoring and automation picks.

Sources

Official pages, all fetched from Singapore on October 1, 2026 (SGT):

• UptimeRobot pricing (00:35) and pricing.md (00:36)
• UptimeRobot terms (00:35) and Fair Use Policy (00:37)
• UptimeRobot: who should use the free plan (00:37)
• UptimeRobot: debugging a monitor showing as down (00:37)
• UptimeRobot: what happens when you downgrade (00:37)
• UptimeRobot: status page subscribers (00:37)
• UptimeRobot: account deletion and inactivity (08:18)
• UptimeRobot API v3 (08:18)
• Better Stack pricing (00:35) and status page product page (08:09)
• Better Stack Terms of Use (00:35)
• Better Stack docs: check frequency (00:39), SSL certificate monitor (00:39), confirmation and recovery period (08:18), request timeout (08:08), keyword monitor (08:08), incident details (00:39), FAQ (00:39)
• Alternatives' pricing pages: Healthchecks.io, StatusCake, HetrixTools and Checkly (00:47), Grafana (00:47), Uptime Kuma GitHub API (08:17)
• Pricing and terms history: Internet Archive snapshots of the UptimeRobot terms and pricing pages and the Better Stack pricing page, fetched between 00:42 and 08:11

Our own test data (probe log, outage results, emails, timelines) was recorded the same day, starting at 00:40 SGT.