What Is Uptime?<\/h2>\n\n\n\n
A service\u2019s overall reliability depends on its uptime stats, which measure how often a server is fully operational over a specific period, typically a year.<\/p>\n\n\n\n
While this number will never be 100%, it should be as close as possible. Even a seemingly nominal drop in percentage translates to significantly more downtime in a year.<\/p>\n\n\n\n
- \n
- 99.9% uptime = 8 hours of downtime annually<\/li>\n\n\n\n
- 99.99% uptime = 52 minutes of downtime annually<\/li>\n\n\n\n
- 99.999% uptime = 5 minutes of downtime annually<\/li>\n<\/ul>\n\n\n\n
Uptime KPI Formula<\/h3>\n\n\n
\n![\"The](\"https:\/\/uptime.com\/blog\/wp-content\/uploads\/2024\/11\/uptime-calculation.png\")
<\/figure>\n<\/div>\n\n\nCalculating Downtime From Uptime<\/h3>\n\n\n\n
As the inverse of uptime, downtime accounts for that small percentage of time when a server is unavailable during the same period for which uptime is calculated<\/a>.<\/p>\n\n\n\n
Referring to our previous example, 99.99% uptime statistics would put the downtime at 0.01%.<\/p>\n\n\n\n
Downtime KPI Formula<\/h3>\n\n\n
\n![\"The](\"https:\/\/uptime.com\/blog\/wp-content\/uploads\/2024\/11\/downtime-calculation.png\")
<\/figure>\n<\/div>\n\n\nWhat Is Availability?<\/h2>\n\n\n\n
Availability refers to the percentage of time a service or system is accessible and <\/strong>working as expected. It\u2019s more informative than uptime because it only includes times when you provide an uninterrupted, fast, error-free experience.<\/p>\n\n\n\n
Consider a website with an uptime of 99.9% in a month, meaning it was only \u201cdown\u201d for around 45 minutes. However, if those users couldn\u2019t log in to their accounts for 5 hours that month, then the availability drops to 99.21, which accounts for both the 45 minutes of planned downtime and the 5 hours of compromised functionality.<\/p>\n\n\n\n
Improving your service availability metrics requires analyzing more granular data to identify opportunities to streamline the processes that contribute to downtime. Mean time to detect (MTTD), mean time to repair (MTTR), and mean time between failures (MTBF) data zoom in on the specific stages of incident management and can help teams prioritize solutions.<\/p>\n\n\n\n
Availability Metrics Formula #1<\/h3>\n\n\n\n
The first option for calculating system availability metrics requires using the uptime statistics and plugging them into a formula that directly accounts for planned and unplanned downtime.<\/p>\n\n\n\n
For example, in one year, you have 8.5 hours of scheduled maintenance and updates and an additional 2.25 hours of unexpected downtime.<\/p>\n\n\n\n
Example:<\/strong><\/p>\n\n\n
\n![\"The](\"https:\/\/uptime.com\/blog\/wp-content\/uploads\/2024\/11\/availability-calculation.png\")
<\/figure>\n<\/div>\n\n\nThis straightforward formula gives you a percentage based on the time the system is up versus down, so it\u2019s great for getting a quick snapshot of availability. However, it doesn\u2019t detail why downtime happens or how to improve it.<\/p>\n\n\n\n
Availability Metrics Formula #2<\/h3>\n\n\n\n
Alternatively, you can use the MMTF and MTTR variables. Unlike the previous formula, which uses only raw application uptime metrics, this formula lets you compare the relationship between failure frequency and recovery time.<\/p>\n\n\n\n
You can then use it to determine where to focus improvements \u2014 increasing stability or improving response times \u2014 and more accurately predict future availability for service level agreements (SLAs)<\/a>.<\/p>\n\n\n\n
Example:<\/strong><\/p>\n\n\n\n
There\u2019s a service failure every 100 hours (MTBF), and it takes 45 minutes to recover (MTTR):<\/p>\n\n\n
\n![\"Additional](\"https:\/\/uptime.com\/blog\/wp-content\/uploads\/2024\/11\/availability-calculation-4.png\")
<\/figure>\n<\/div>\n\n\nAPI Availability Metrics<\/h3>\n\n\n\n
Just like with overall system availability, it is important to monitor your application programming interface (API)<\/a>, and it should be available as close to 100% of the time as possible, whether they\u2019re yours or a third party.<\/p>\n\n\n\n
Even if you keep your APIs in perfect working order, third-party API downtime can still drag your service down with it. Be familiar with the third party\u2019s SLA<\/a> so you can plan for service interruptions and know the guidelines for what to do if those thresholds aren\u2019t abided by.<\/p>\n\n\n\n
Web and Network Performance Metrics<\/h2>\n\n\n\n
Uptime metrics tell you how often your services are online, but that\u2019s only part of the story. A service that\u2019s technically \u201cup\u201d can still leave users frustrated if the interactions feel sluggish, so your teams will also want to stay on top of the following web performance KPIs<\/a>.<\/p>\n\n\n\n
Response Time<\/h3>\n\n\n\n
Once a server receives the client-end request, time starts ticking to determine how long the client\u2019s system takes to get that data back.<\/p>\n\n\n\n
However, response time is often divided into more specific real user monitoring sub-metrics<\/a> so your team can better identify performance bottlenecks, such as network latency.<\/p>\n\n\n\n
First Contentful Paint (FCP)<\/h3>\n\n\n\n
The FCP is the time it takes for the first piece of meaningful content, such as a header, hero image, text, etc., to appear on the user\u2019s screen. Google recommends keeping the FCP under 2 seconds to keep users satisfied.<\/p>\n\n\n\n
Total Blocking Time (TBT)<\/h3>\n\n\n\n
After the FCP, the page will visually load in its entirety but will still be unresponsive to input. A high TBT typically means the browser must work harder to process the JavaScript or parse CSS. Optimizing script execution can help bring that number below the recommended 200 milliseconds.<\/p>\n\n\n\n
Time to Interactive (TTI)<\/h3>\n\n\n\n
It\u2019s one thing for a page to appear quickly, but another for it to be ready for the users to interact with. That\u2019s why one of the uptime metrics worth monitoring is how long it takes for a page to become entirely usable.<\/p>\n\n\n\n
The faster the TTI, the faster users can click, scroll, and type without being held up by scripts or processes still loading in the background.<\/p>\n\n\n\n
Page Speed<\/h3>\n\n\n\n
Page speed<\/a> is the cumulative time it takes for the browser to fully load and make a web page usable, starting from the moment of the initial request until all content is visible and scripts are executed.<\/p>\n\n\n\n
Users expect pages to load in around 3 seconds, but the faster you are, the less likely they are to bounce. Google reports that the probability of a bounce<\/a> from a page that loads in 3 seconds is 32%, compared with the 90% bounce rate of one that loads in 5 seconds.<\/p>\n\n\n\n
With so much of your site\u2019s success hinging on load times, page speed monitoring<\/a> is non-negotiable. That way, when something causes a performance bottleneck that\u2019s killing your on-page linger times, you get an instant alert that sets fixes in motion long before they can impact your broader user base.<\/p>\n\n\n\n
Latency<\/h3>\n\n\n\n
When you conduct a ping test, you measure the network latency, which is how long it takes a user to receive the requested data packet. So, if the client device requests a data packet at 08:02:00.000 and the data center receives the request at 08:02:00.138, then the latency is 138 milliseconds.<\/p>\n\n\n\n
Naturally, the lower the latency, the faster websites and applications are. It provides quicker feedback to the user and an overall more pleasant experience engaging with a digital service. According to Deloitte<\/a>, latency is the number one driving factor behind high bounce rates on mobile sites.<\/p>\n\n\n\n
If your latency is high, it\u2019s a sign that something\u2019s slowing down the data flow, whether it be the physical distance between the user and the server or a sudden surge of traffic eating up capacity. Any spikes in latency should be analyzed to determine how to get data moving through the network path again.<\/p>\n\n\n\n
Bandwidth Utilization<\/h3>\n\n\n\n
IT teams monitor bandwidth utilization to determine how well the current servers meet users\u2019 needs, expressed as a percentage of the total available capacity.<\/p>\n\n\n\n
This utilization metric will vary over time depending on the traffic a web application experiences. DevOps teams should be prepared to scale as appropriate to ensure excellent website performance<\/a> without wasting resources.<\/p>\n\n\n\n
For example, let\u2019s say that your bandwidth utilization consistently hovers in the 95%-99% region. That\u2019s a sign that your network is just about at capacity, and there\u2019s a good chance that users are experiencing slower speeds. At that point, it\u2019s time to consider scalability options to serve users with the experience they expect.<\/p>\n\n\n\n
Low bandwidth utilization won\u2019t necessarily affect users but can affect your bottom line. If traffic needs are met by 40%-50% of the bandwidth, downgrade capacity to reduce costs.<\/p>\n\n\n\n
Throughput<\/h3>\n\n\n\n
The easiest way to understand the relationship between the theoretical capacity of bandwidth and the concrete throughput data is by picturing a water pipe.<\/p>\n\n\n\n
The total capacity of the pipe is the bandwidth, and throughput is the amount of water that flows through it within a given time frame. So, even if you have a wide pipe (high bandwidth), there can be blockages along the way that decrease the rate at which water can flow (low throughput).<\/p>\n\n\n\n