Uptime monitoring for SaaS — before the first ticket.
Your public API, your sign-in flow and last night’s billing job are each watched as their own check, not inferred from a homepage that still returns 200. A failure is confirmed from other regions, then it pages whoever is on call — in Slack, PagerDuty or 10 other channels.
Step breakdown
All 2 steps passedFailed at step 2244 ms · 02:13236 ms · 02:147-day averagesLast runAssertions — step 2
3 of 3 passing0 of 3 passedResponse — step 2
200 · 96 ms502 · 84 msRecent Runs
every minute · rotating locations
New York✗ Failed at step 20.24 s
Frankfurt✗ Failed at step 20.24 s
London✓ All 2 steps passed0.25 s
Sydney✓ All 2 steps passed0.26 s
Amsterdam✓ All 2 steps passed0.23 sNew York✓ All 2 steps passed0.24 s
Tokyo✓ All 2 steps passed0.25 sFour beliefs that lose SaaS customers
Each one sounds reasonable. Each one ends with a churned customer you never got to argue with.
"If something broke, customers would tell us."
The ones who tell you are the loyal ones. A prospect who hits a broken signup closes the tab and never becomes a customer — there's nobody to complain, and nothing in your inbox to investigate.
"We're on AWS — uptime is their job."
Their SLA covers their infrastructure, not your product. A bad deploy, an expired certificate, a wedged queue worker are all yours — and the provider's status page stays green through every one of them.
"The app loads, so we're up."
A SaaS is a bundle of capabilities, not one page. The dashboard can load while the public API 502s, sign-in fails or the billing job quietly skips a night — each breaks on its own, and "up" hides all of it.
"Admitting incidents publicly makes us look bad."
Silence looks worse. A customer who finds a status note files no ticket — and remembers you told them before they asked. A customer who finds nothing assumes you don't know either.
"Three nines is basically perfect" is the biggest one. 99.9% uptime allows 43 minutes down a month. On a brochure site that is a rounding error — but customers work inside a SaaS. Multiply 43 minutes by 500 customers: 21,500 customer-minutes, 358 hours a month of someone finding your product broken.
Renewals aren't decided by your uptime percentage. They're decided by who found out first, and how fast it was fixed.
So what does 02:14 look like on the night the API starts throwing 502s — when something is running the login chain?↓ minute by minute
The night the API broke
At 02:14 the account endpoint started answering 502. The dashboard still loaded, the homepage ping stayed green, and every integration calling that endpoint was already failing.
That's the API covered. But a SaaS breaks at four layers — app, API, flows, jobs — and each one fails on its own.↓ every layer
Seven checks, one alerting pipeline
Outbound checks hit your API and pages, a real browser replays login and signup, your jobs ping in, a snippet watches real users — all into one dashboard. Each family is counted on its own: uptime checks and heartbeats generously, API chains and browser flows tightly.
Built for how SaaS breaks
The API your customers call
A 200 on your homepage says nothing about the endpoint their integrations hit — so today a customer tells you. Uptimia runs a real request chain against your public API instead, as often as every minute: log in, grab the token, call the protected endpoint, read the response.
- Chains up to 15 steps — each asserts on status, JSON, headers or text, and passes values forward
- Real auth — extract a token from the login response and reuse it as
{{token}} - Confirmed, not flaky — a failing step is checked from up to three locations before an incident opens
Login and signup in real Chrome
After a deploy, the first person to try signing in should be a robot. Uptimia replays login and signup in a real Chrome browser from 13 locations, as often as every 10 minutes, and opens an incident the moment a step fails — with a screenshot of the page as it broke.
- A real browser — go to the page, fill the fields, click, check the text
- Screenshot on failure — the waterfall shows the step that broke and what the page looked like
- Step timings — per-step durations, so a slowing flow shows up before it fails
The billing job that never ran
A cron that dies doesn't say so — nothing looks "down" from the outside while invoices quietly don't go out. Heartbeats flip that: your job pings Uptimia when it finishes, and a missing ping is the incident.
- One ping URL —
curla unique/p/{token}at the end of a cron, worker or backup script - Interval or cron schedule — an expected cadence plus grace period; a ping missing past grace opens an incident
- Start & fail signals too — catch a job that started but never finished, or reported its own failure
A status page on your domain
Before opening a ticket a customer looks for a page that says you already know. Put one on your own domain — your logo, the Uptimia badge switched off — showing live health, 90 days of history and every incident note, with subscribers emailed on each update.
- Your domain, automatic SSL —
status.yourapp.comover HTTPS, the "Powered by Uptimia" badge removable - Sections & subscribers — group monitors by area, post incident and maintenance updates, notify subscribers
- Public or private — open to your customers, or password-protected
One incident, your team and your status page
The same confirmed incident pages whoever is on call and updates the page your customers are already refreshing.
Microsoft Teams12 alert channels, one contact list — and the status page your customers watch, updated from the same incident.
Browse the full integrations directory →An outage should page you.Not your customers.
Every monitor type in the 30-day trial — 50 API chains, 50 login flows, 50 heartbeats, 500 uptime checks.
Set up API, flows and jobs
Your product's critical paths can be under watch this afternoon.
Point checks at your product
Add an uptime check on the app, an API chain against your public endpoints, and a transaction that replays your login.
Wire heartbeats into your jobs
Drop the ping URL at the end of each cron, worker or backup. A missed ping becomes an incident.
curl -fsS uptimia.com/p/hb_9f3c…
Route alerts & publish status
Send alerts to Slack and PagerDuty, on Professional set the escalation ladder, and put uptime and flows on a status page.
Also included
Watch what real users feel
A passive JavaScript snippet reports real visitors' load times by device, browser and location.
Automate from the API
Create monitors and status pages from your own tooling — spin up checks in a deploy script.
Maintenance windows
Shipping a release? Schedule the window — checks pause, alerts stay quiet, the status page shows planned work.
One incident, one alert
A storm becomes a single digest, not a hundred pings — with a signed link to acknowledge and MTTA tracked. Grouping and acknowledgement ride the escalation ladder, so they start at Professional.
Recovery notices
When the API comes back, the engineers who were paged get the all-clear too.
Free tools for the debugging afterwards
Trace a redirect header-by-header with the HTTP Status Checker, or see what each "nine" allows with the Uptime Calculator.
What is uptime monitoring for SaaS?
Uptime monitoring for SaaS is watching the parts of a product customers depend on — the public API, login and signup flows, and the background jobs behind them — so your team is alerted the moment one breaks. A homepage ping stays green while your API returns 502s, sign-in fails, or a nightly job stops.
Green while customers are stuck
Your check passes while the thing customers pay for is down — you find out from a ticket.
You watch every layer
API, flow and job checks feed one pipeline — the failure reaches an engineer, not a customer.
How much downtime each "nine" allows
"99.9% uptime" sounds airtight until you turn it into minutes — here's what each level permits.
Open the uptime calculator →| Uptime | Downtime / month | Downtime / year |
|---|---|---|
| 99% | 7h 18m | 3d 15h |
| 99.9% | 43m 49s | 8h 46m |
| 99.95% | 21m 54s | 4h 23m |
| 99.99% | 4m 23s | 52m 35s |
| 99.999% | 26s | 5m 15s |
SaaS monitoring FAQ
01What is uptime monitoring for SaaS?+
02How is this different from just pinging my homepage?+
03Can I monitor my public API?+
{{variable}} templating between steps. It runs as often as every minute on every plan, and a failing step is re-run from up to three locations before an incident opens. A chain is the most expensive check to run, so it's counted tightly: 1 API monitor on Basic, 10 on Professional, 100 on Enterprise — while the 30-day trial carries 50, more than any plan below Enterprise. Size the plan on the chains you intend to keep.04Can it catch a broken login or signup?+
05Can I get alerted when a background job stops?+
06How fast can it check?+
07Can I give my customers a status page?+
08Can I restrict a teammate to only some monitors?+
09Do you support SSO, and can I get SLA reports?+
10Which alert channels can my team use?+
11Do I need to install anything in my app?+
curl to the ping URL); real-user monitoring is a small JavaScript snippet. No agent unless you also want server metrics.Your product is the uptime.
Put your API, login flow and background jobs under watch this afternoon — and stop hearing about outages from customers.