Uptime vs availability: reachable is not usable, how to count partial outages and what to report on your status page

The difference in uptime vs availability is the difference between reachable and usable. Uptime is the share of time a system is running and answering. Availability is the share of time, or of requests, in which users can actually complete what they came for. A server can report 100% uptime for a month while checkout was broken for an afternoon, so if you promise or report anything to customers, measure availability from the user's side and publish it per component.

Uptime vs availability: the working definitions

Uptime is a property of a machine or process. The host is powered on, the process is alive, the port accepts connections, the health endpoint returns 200. It answers the question: is it running?

Availability is a property of a service as experienced by its users. A request arrives, gets a correct response, within a time the user accepts. It answers the question: can people use it?

Both are usually expressed as a percentage, which is why they get mixed up. The formulas look similar but count different things:

uptime                    = time the system was running / total time
availability (time-based) = minutes in which users could succeed / total minutes
availability (request)    = successful valid requests / all valid requests

The definition of "succeed" is where all the work is. If you have not written it down, you are measuring uptime and calling it availability.

Where the two numbers split apart

Most real incidents in small SaaS teams do not take a server offline. They leave everything running and break something in between. Typical cases where uptime stays green and availability drops:

• The web server returns 200 OK with an error page, a blank shell or a maintenance banner rendered by the framework.
• The app is up, but the database, cache, payment provider or email API it depends on is failing, so login or checkout throws errors.
• One region, one CDN edge or one DNS resolver path is broken, so some users cannot reach you while your own checks pass.
• Responses technically succeed but take 15 or 30 seconds. Users give up long before the timeout of your health check.
• Background work stops: emails are not sent, exports never finish, webhooks pile up. Every endpoint is fine, the product is not.

It also works the other way round. With redundancy, availability can be higher than the uptime of any single part. If one of three app servers is down for an hour behind a load balancer, host uptime drops, but users may never notice. That is why host uptime is a poor customer-facing metric in both directions: it overstates problems that redundancy absorbs and hides problems that no single host owns.

Uptime tells you whether your infrastructure is running; availability tells you whether your customers can use the product. Report the second one.

Partial outages and degraded performance: how do you count them?

A binary up/down model breaks as soon as only part of the product fails or everything gets slow. You need explicit rules, decided before the incident, not during the monthly report.

Partial outage

A partial outage means some users or some features are affected. The cleanest way to count it is to split the service into components that match what users do, then compute availability per component. "Checkout unavailable for 90 minutes" is honest and useful. Folding it into one global percentage either hides it or exaggerates it.

If you need a single number, request-based availability handles partial failures naturally: if 20% of requests fail for an hour, that hour counts as 20% bad, not 0% or 100%.

Degraded performance

Degraded performance is the hardest case, because nothing fails. Pick a latency threshold above which a request or minute counts as unavailable, and write it next to the formula. For example: a minute is bad if checks fail or if the response time from users' regions exceeds 2 seconds. The exact value is your decision and should come from what your users tolerate, not from a benchmark.

Three common options, from strict to lenient:

• Count slow as down above the threshold. Simple and honest, best for interactive endpoints like login or search.
• Weight it, for example a slow minute counts as half a bad minute. More nuanced, harder to explain.
• Track it separately as a latency objective next to availability. Common when you already work with SLOs; the walkthrough from SLI to SLO to SLA shows how such indicators turn into promises.

A worked example

A 30-day month has 43,200 minutes. Assume no server went down, checkout returned errors for 90 minutes, and the whole app was slow above your threshold for another 120 minutes.

host uptime                     = 43200 / 43200            = 100.00%
checkout availability (errors)  = (43200 - 90) / 43200     = 99.79%
checkout availability (+ slow)  = (43200 - 210) / 43200    = 99.51%

Same month, three defensible numbers. Which one you report depends on your written definition. The mistake is reporting the first while users experienced the third.

How to measure availability from the user's view

Measuring availability means testing what users do, from where they are, with success criteria stricter than "the port is open". A practical sequence:

1. List your user journeys. Usually three to six: load the app, log in, the core action (create a project, send a message), checkout, the public API. Each becomes a component.
2. Define success per journey. Expected status code, a string in the body that only appears when the page really works, and a latency ceiling. A health endpoint should touch its real dependencies, not just return a constant.
3. Check from outside, from several regions. Internal checks cannot see DNS, TLS, CDN or routing problems. Requiring failures from more than one location before alerting keeps single network blips out of your availability numbers.
4. Check the API like a client would. Authenticated requests, realistic payloads, validated response bodies. The guide on monitoring API endpoints with status codes, latency and body checks covers the details.
5. Cover background work with heartbeats. Queues and scheduled jobs that stop silently are an availability problem even though no request fails.
6. Cross-check with server-side success ratios. Synthetic checks sample; logs and metrics see every real request. Use both: checks for fast detection, request ratios for the monthly number.

A minimal external check that tests usability rather than reachability:

code_time=$(curl -s -o /tmp/body -w "%{http_code} %{time_total}" \
  --max-time 10 https://app.example.com/api/health)
code=${code_time% *}; t=${code_time#* }

[ "$code" = "200" ] || echo "FAIL status $code"
grep -q '"db":"ok"' /tmp/body || echo "FAIL dependency"
awk -v t="$t" 'BEGIN { exit !(t > 2.0) }' && echo "DEGRADED ${t}s"

And a request-based availability ratio from metrics, here in PromQL, counting 5xx as failures:

sum(rate(http_requests_total{job="api",code!~"5.."}[30d]))
/
sum(rate(http_requests_total{job="api"}[30d]))

Decide what "valid" means before you trust this number. Requests rejected with 4xx because of a client bug or an attacker usually should not lower your availability; a 429 caused by your own overloaded rate limiter probably should.

What should you report on a status page?

Users visit a status page to answer one question: is the thing I am trying to do broken, and is it me? Host uptime does not answer that. Availability per component does.

• Components named after user journeys, not servers: "Dashboard", "Login", "Payments", "Public API", "Email delivery". Nobody outside your team knows what worker-03 is.
• Status levels with written criteria. For example: Operational when checks pass within the latency threshold; Degraded performance when requests succeed but exceed the threshold; Partial outage when a feature, region or share of users fails; Major outage when the core journey fails for most users; Maintenance for announced work.
• History per component, so a 90-minute checkout incident is visible as such and not averaged away.
• Incident updates in plain language that say which journeys are affected and what users should do.

Whether degraded time turns a day's bar yellow or red should follow the same rule you use for your availability number. If the page shows green while support is flooded, the page loses its purpose. The article on status page components, honest status levels and update cadence goes deeper into that part.

Measuring availability with m0nitor

If you use m0nitor, the building blocks map onto the steps above. Uptime checks for websites, APIs and servers run on a fixed interval from probes in several regions, and an outage is only confirmed when multiple locations agree, which keeps single-route blips out of the record. Monitor types include HTTP(S), TCP and UDP ports, SSH, ping, DNS, SSL certificate expiry and heartbeat monitors for scheduled jobs, plus manual static components for things you cannot probe directly.

Hosted status pages show those monitors as components with incident history, can run on a custom domain and notify email subscribers. Other monitoring setups work just as well with the approach in this article; what matters is that checks test usability and components reflect user journeys.

FAQ

Is uptime the same as availability?

No. Uptime measures whether a system is running and reachable. Availability measures whether users can successfully use the service within an acceptable response time. A system can be up but unavailable, for example when it returns errors from a failed dependency or responds too slowly to be usable.

How is availability calculated?

Either time-based, as good minutes divided by total minutes, or request-based, as successful valid requests divided by all valid requests. Both need a written definition of success that includes status codes, response content and a latency threshold. Request-based availability handles partial outages more accurately; time-based is easier to explain in an SLA.

Can availability be higher than uptime?

Yes, at the level of individual components. With redundancy, one server or instance can be down while a load balancer routes traffic to the others, so users see no failure. That is why the uptime of a single host says little about what customers experience.

Does scheduled maintenance count against availability?

That depends on your definition. Many SLAs exclude announced maintenance windows from the calculation, but users still cannot use the service during that time. A common approach is to exclude it from the contractual number, show it as maintenance on the status page and keep an internal number that includes it.