Skip to content

← Blog

99.9% Uptime vs Response Time: Why Small Teams Need Separate SLOs

By Nick Phillips, Founder

99.9% Uptime vs Response Time: Why Small Teams Need Separate SLOs

Hand-drawn timing motifs frame article title

Uptime tells you whether a site was reachable; response time tells you how fast it answered. They sound like cousins, but they measure completely different failure modes: a server can be up and still too slow to use, and both numbers matter for the same reason, they describe what your visitors actually experienced. The catch is that each one gets measured differently, with its own thresholds and its own blind spots, so treating them as one blended “health” score hides real problems.

TL;DR:

  • A 99.9% target permits about 43 minutes of monthly downtime; 99.99% permits 4.3 minutes, while 99.999% allows roughly 26 seconds.
  • Before comparing uptime readings, document the measurement window, endpoint, timeout, maintenance policy, and whether calculations count downtime or failed requests.
  • For field performance, use the 75th percentile: Google’s good thresholds are LCP at 2.5 seconds or less and INP at 200 milliseconds or less.
  • Set probe timeouts tighter than your slowest acceptable response, and compare mobile and desktop separately; visitors may give up before a monitor records success.
Otterwatch
Keep Site Availability in View
Otterwatch checks whether your sites are up while monitoring SSL certificates, keeping essential signals visible without a wall of alerts.
Visit Otterwatch

Table of Contents

What uptime (availability) actually measures

Uptime, or availability, is the share of a measurement period during which your service responded successfully, according to the AWS Well-Architected reliability pillar. That sounds simple until you ask over what period. Most providers report it monthly, annually, or as a trailing figure across a few years, and the window you pick changes what the percentage hides.

There are two common ways to calculate it. Time-based uptime counts the minutes your service was marked down against the minutes in the period. Request-based uptime counts failed requests against total requests, which is the method AWS CloudWatch uses for its availability SLOs. A service that fails for one minute during low traffic looks very different depending on which method you use, since time-based math treats that minute the same regardless of how many requests it affected.

This is where the “nines” come from. Each additional nine shrinks your allowed downtime dramatically:

  • 99.9% uptime allows a few tens of minutes of downtime per month, per Google Cloud’s reliability guidance.
  • 99.99% uptime allows just a few minutes of downtime per month.
  • 99.999% uptime allows tens of seconds of downtime per month.

Before you compare two uptime numbers, check what’s behind them. Different providers (or different tools watching the same site) can report wildly different uptime percentages for identical real-world behavior, because the probe endpoint, the timeout threshold, and how scheduled maintenance gets counted are all judgment calls. A health check hitting a lightweight status endpoint will almost always look healthier than one hitting your database-backed homepage, and a provider that excludes maintenance windows will post a rosier number than one that doesn’t.

What response time and latency actually measure

If uptime answers “was it there,” response time answers “how fast did it answer.” The terms around this get used loosely, so it helps to pin them down:

  • Latency is the delay before a response starts arriving, often used interchangeably with response time but technically the travel time, not the full round trip.
  • Response time is the full elapsed time from request to completed response.
  • TTFB (Time to First Byte) is the gap between a request and the first byte of the response, a useful proxy for server and network speed.
  • LCP and INP are user-centered metrics from Google’s Core Web Vitals that measure how fast the main content appears and how responsive the page feels during interaction.

Averages are a poor way to report any of these, because a handful of slow outliers get smoothed away by thousands of fast requests, hiding exactly the experience your worst-off visitors had. That’s why performance reporting leans on percentiles instead. Google’s PageSpeed Insights evaluates field data at the 75th percentile, meaning the reported number reflects what three out of four visits experienced or beat, which deliberately weights in people on slower devices and networks rather than flattering the fastest users.

Good thresholds depend heavily on what you’re measuring. Google’s Core Web Vitals set “good” at an LCP of 2.5 seconds or less and an INP of 200 milliseconds or less, both judged at the 75th percentile, with TTFB’s experimental “good” mark at 800 milliseconds, per Google’s Core Web Vitals documentation. So is 100 milliseconds good? For a database query backing an API, yes, that’s fast. For a page’s full LCP, 100 milliseconds would be exceptional and rarely achievable once images and fonts load. Device type and network conditions shift the same backend time into a very different experienced response time, which is why device segmentation matters as much as the raw number.

Setting up uptime and response time as separate SLIs

Treating availability and latency as two separate service-level indicators, not one combined health check, is the single biggest mindset shift most small teams need to make. Here’s how that plays out in practice:

  1. Pick your checking method. Probe-based reachability checks hit a specific endpoint on a schedule and record whether it responded and how fast; real-user monitoring instead captures actual visitor sessions in the browser. Probes are cheap and consistent; real-user data reflects what people genuinely experienced, including their device and network.
  2. Define your availability SLI. AWS CloudWatch calculates availability as successful responses divided by total requests, and you get to decide what counts as a failure. Many teams treat 5xx server errors as faults but count 4xx client errors as successful transactions, since those reflect client behavior rather than service health, per CloudWatch’s SLO documentation.
  3. Define your latency SLI separately, by percentile. A single average latency number tells you almost nothing about tail behavior. Choose a percentile that matches the workload, AWS suggests something like the 95th percentile for bulk operations and the 75th for interactive ones, since interactive traffic needs more of the audience to feel fast.
  4. Watch your timeouts carefully. The probe timeout you configure, and the client timeout your actual visitors experience, don’t have to match, and when they don’t, your reported uptime can disagree with what people actually saw. A response that arrives two seconds after a mobile browser gave up is a failure to that visitor even if your monitor logged it as a success.
  5. Document your choices before comparing numbers across tools or time periods. Endpoint, timeout, aggregation window, and percentile choice all belong in writing somewhere your team can reference, not just in the monitoring tool’s settings screen.

Pro Tip: Set your probe’s timeout a little tighter than your slowest acceptable real-world response, not looser, so a monitor failure actually means something is wrong rather than masking a slow but “successful” request.

What “good” looks like for each metric

There’s no universal good number for either metric, only numbers that match what your service needs to do and what users will tolerate. The nines-of-uptime framework gives you concrete downtime budgets to reason from:

Uptime target Max downtime per month Typical use case
99.9% Several tens of minutes Small sites, internal tools, early-stage products
99.99% Few minutes Customer-facing SaaS, e-commerce
99.999% Tens of seconds Payment systems, critical infrastructure

These figures come from Google Cloud’s reliability guidance, and our own breakdown of what each nine actually costs you in downtime walks through the math in more detail if you want to see how it compounds across a year.

Performance thresholds work the same way: a 200-millisecond latency SLO might be reasonable for an API endpoint, while Core Web Vitals asks for an LCP under 2.5 seconds and an INP under 200 milliseconds, measured at the 75th percentile so it reflects a realistic majority of visits rather than your fastest test run. A few things to weigh when you’re picking your own targets:

  • Match the target to the workload, not to whatever number looked impressive in someone else’s blog post.
  • Account for mobile versus desktop separately, since the same backend can produce very different experienced load times depending on device and network.
  • Weigh the cost of chasing another nine. Going from 99.9% to 99.99% usually means redundant infrastructure across multiple zones, which raises both reliability and your bill.

Copy-pasting someone else’s SLO target rarely works, because their traffic pattern, user expectations, and failure tolerance are not yours.

When a fast failure and a slow success collide

A site can be “up” by every monitoring definition and still fail its visitors, which is the gap that trips up teams who only watch one metric. A few scenarios where this shows up:

  • The timeout mismatch. Your server eventually returns a 200 response, but it arrives after the visitor’s browser or mobile app already gave up and showed an error, so your uptime log says success while the user saw a failure.
  • Partial degradation. A page loads but a slow third-party script or an overloaded database delays the parts users actually need, like search results or checkout, so the endpoint is reachable but the experience isn’t.
  • Regional latency spikes. A service hosted in one region can stay perfectly reachable while visitors on the other side of the world experience response times multiple times higher, a pattern worth checking with tools built for specific destinations, like QRlytics’ notes on QR code uptime, which look at how reachability and response time interact for a very specific type of endpoint.

Distributed systems research frames this tension formally. The CAL theorem generalizes the older CAP theorem by quantifying how consistency, availability, and latency trade against each other rather than treating them as a strict either-or choice, which is a useful mental model even if you never touch the math. In practice, this means: favor availability when any response, even a slightly stale or slightly slow one, beats showing an error; favor latency when a fast, fresh answer matters more than guaranteeing every single request succeeds. Monitoring both metrics separately is what lets you actually see which situation you’re in, instead of guessing.

Our take: why small teams should track both, simply

Our take: why small teams should track both, simply — overview diagram

We built Otterwatch around a simple observation: most monitoring tools are built for large ops teams with dashboards to spare, and a solo founder or a five-person agency doesn’t need forty graphs to know if their site is reachable. Our focus starts with SSL certificate expiry, since an expired cert takes a site down just as effectively as a server crash, and reachability checks ride along as the calm bonus, not an afterthought buried in a noisy alert feed.

For a small team, that usually means one plain uptime check per important domain and one simple latency threshold you’d actually notice crossing, documented once so you’re not relearning your own setup every time something breaks. We cover low-noise uptime monitoring built around certificates and 5-minute setup for small teams in more detail if you want the practical checklist.

— Nick Phillips

Otterwatch: free certificate and uptime monitoring for small teams

We give you a single calm place to watch SSL certificate expiry and basic reachability together, without the dashboard sprawl that most monitoring platforms assume you want. Otis, our ranger-otter mascot, sends a plain email heads-up well before a certificate expires instead of a wall of red alarms, and your uptime checks run quietly alongside that same plan.

Monitoring five domains, including certificate expiry alerts and uptime checks, costs nothing to start, no credit card required, through our Free plan. If you manage certificates and reachability for more sites, or want deeper change-detection on top of the basics, our Pro plan runs $15 per month on the same pricing page. Curious whether a certificate on one of your domains needs attention right now? Run it through our free SSL certificate checker and see exactly what’s expiring and when.

FAQ

What is latency vs response time?

Latency is the delay before a response begins arriving, essentially the travel time for a request, while response time is the full elapsed time from sending the request to receiving the complete response. In casual use the terms often get swapped, but response time technically includes processing time that pure latency does not.

What does “uptime” mean in the context of websites?

Uptime is the proportion of a measurement period, typically a month or year, during which a website responded successfully to checks, according to AWS’s reliability guidance. It can be calculated by time (minutes down versus minutes total) or by request (failed requests versus total requests), and the method affects the reported number.

Is 100 ms response time good?

For a backend API call or database query, 100 milliseconds is generally fast. For a full page load metric like Largest Contentful Paint, Google’s Core Web Vitals set the “good” threshold at 2.5 seconds, not 100 milliseconds, so the answer depends entirely on which stage of the response you’re measuring, per Google’s Core Web Vitals guidance.

What is a good uptime?

A commonly cited target is 99.9% uptime, which allows about 43.2 minutes of downtime per month, while more critical services often aim for 99.99% (about 4.3 minutes) or 99.999% (about 26 seconds), based on Google Cloud’s reliability documentation. The right target depends on how critical your service is and how much downtime your users and budget can realistically tolerate.

Sources

Catch the next cert expiry before your users do.

Otterwatch checks your SSL certificates daily and emails you 30 days before they expire. Five sites free.

Start watching →