SaaS Uptime Monitoring: Uptime Monitoring for SaaS Apps, APIs and Uptime SLAs

For most B2B SaaS products, 99.9 percent monthly availability is the working standard, and it is the figure most commonly written into customer contracts. That allows about 43 minutes of downtime in a 30 day month. Products sold to enterprise buyers often commit to 99.95 percent, and infrastructure products such as payment or identity APIs aim at 99.99 percent.

The table below turns each percentage into the minutes you are actually allowed to be down. The numbers matter more than the nines, because they tell you how much of the budget one slow rollback consumes.

Allowed downtime is calculated as the minutes in the period multiplied by the share not covered by the SLA, so 43,200 minutes in 30 days times 0.001 gives 43.2 minutes. Most contracts exclude announced maintenance windows, which is why the maintenance notice matters as much as the monitor.

This is the point most SaaS teams miss when they pick a monitoring plan on price. A monitor that checks every 5 minutes can only locate the start and the end of an outage to within 5 minutes each. A single incident can be overstated or understated by several minutes, and a short outage between two checks may never be recorded at all.

Against a 99.9 percent budget of 43 minutes, that uncertainty is tolerable. Against 99.95 percent, where the whole month's budget is 21.6 minutes, a 5 minute interval means one measurement error can be a quarter of your allowance. At 99.99 percent, a 5 minute interval is longer than the entire monthly budget, so the monitor cannot tell you whether you met the SLA.

The practical rule: your check interval should be small compared with the downtime your SLA allows. 60 second checks are the sensible floor for 99.9 and 99.95 percent commitments. TrackDowntime runs 60 second checks on Professional and Enterprise and 5 minute checks on Starter, which is fine for an internal tool and not what we would recommend for a product with a written availability commitment.

The common mistake is monitoring only the marketing site. It is usually hosted on a different platform from the product, it is heavily cached, and it can stay perfectly healthy through a full application outage. Here is a working set for one product in one region.

That is six endpoints for one product, which fits Professional with room for a staging environment, a second region or a second product. Teams running several products or per customer instances usually outgrow a per endpoint plan, which is what Enterprise at $299 a month with unlimited endpoints is for.

Being precise here saves you from buying the wrong tool or trusting the right one for the wrong job.

Caught reliably. A 5xx from a crashed process, a failed deploy or a database that stopped answering. A load balancer returning 502 or 503. An API route that starts returning 401 or 403 because a key rotation went wrong, as long as you set the expected code. A DNS failure after a nameserver or record change. An expired certificate on your app domain, which every customer sees as a full page browser warning. An endpoint that has become too slow to use, if the timeout sits where slow stops being acceptable.

Not caught by an HTTP check. A page that returns 200 and renders an error inside it, a broken button, a background job queue that stopped processing, or a feature that fails only for some tenants. TrackDowntime does HTTP and HTTPS checks with expected status codes, timeouts, custom headers and SSL expiry. It does not match page content, does not script a browser through a user journey, does not check from several regions at once, and does not host a public status page. If a scripted login journey or APM tracing is what you need, those are separate product categories, and they sit alongside an uptime monitor rather than replacing it.

The reason to start with an external monitor anyway is that it is the only view that matches the customer's. Internal dashboards report on the infrastructure you know about. An outside check reports on what a customer's browser or script actually receives.

Sooner or later a customer disputes an outage, asks for a service credit, or sends a security questionnaire that asks how availability is measured and how long the evidence is kept. The answer that holds up is an independent incident log: when each outage started, when it ended, how long it lasted, and what the endpoint returned.

TrackDowntime stores that for every endpoint. Professional keeps 90 days of history, which covers a quarterly business review. Enterprise keeps it with no expiry, which is what you want when contracts run annually and credits are calculated at renewal. Both can export the record to CSV so the number in the customer report comes from the same data you would show in a dispute.

Thirty days is not enough for this job, which is why we do not recommend Starter for a product with a written SLA. For a deeper comparison of how long each vendor keeps downtime history and what its reports contain, see the review of uptime monitoring tools for SLA reports and downtime evidence, and for how each incident is logged, the website downtime tracker.