[{"data":1,"prerenderedAt":320},["ShallowReactive",2],{"blog-\u002Fblog\u002Fhow-to-read-an-uptime-report":3},{"id":4,"title":5,"author":6,"body":7,"category":293,"date":294,"description":295,"extension":296,"faqs":297,"image":310,"meta":313,"navigation":314,"path":315,"readingTime":316,"seo":317,"stem":318,"__hash__":319},"blog\u002Fblog\u002Fhow-to-read-an-uptime-report.md","How to Read an Uptime Report: What the Numbers Actually Mean","Monitoristic Team",{"type":8,"value":9,"toc":283},"minimark",[10,19,22,25,30,36,39,67,70,76,80,83,86,106,117,121,124,150,153,179,184,188,191,211,218,223,227,230,273,277,280],[11,12,13,14,18],"p",{},"You open your monitoring dashboard, and there it is: ",[15,16,17],"strong",{},"99.7% uptime",". Sounds great, right?",[11,20,21],{},"Maybe. Maybe not. That number alone doesn't tell you whether you had one long outage or fifty short blips. It doesn't tell you if the downtime happened at 3 AM or during your biggest traffic spike of the month.",[11,23,24],{},"Uptime reports are full of useful data — but only if you know what to look at and what to ignore. Here's how to read one without getting lost in the numbers.",[26,27,29],"h2",{"id":28},"uptime-percentage","Uptime Percentage",[11,31,32,33],{},"This is the headline metric. It answers one question: ",[15,34,35],{},"what fraction of the monitoring period was your site reachable?",[11,37,38],{},"Here's what the common targets look like in practice:",[40,41,42,49,55,61],"ul",{},[43,44,45,48],"li",{},[15,46,47],{},"99.9% (three nines)",": ~43 minutes of downtime per month",[43,50,51,54],{},[15,52,53],{},"99.95%",": ~22 minutes per month",[43,56,57,60],{},[15,58,59],{},"99.99% (four nines)",": ~4 minutes per month",[43,62,63,66],{},[15,64,65],{},"100%",": Either genuinely perfect or your check interval is too long to catch short outages",[11,68,69],{},"The percentage is useful for SLA tracking and trend comparison, but it hides important context. A site with 99.5% uptime that had one 3-hour planned maintenance at 2 AM is in better shape than a site with 99.8% uptime that had fifteen random 1-minute outages during business hours.",[11,71,72,75],{},[15,73,74],{},"What to do with it",": Compare month over month. A steady 99.9% is healthy. A trend from 99.95% down to 99.7% over three months means something is degrading and needs attention.",[26,77,79],{"id":78},"response-time","Response Time",[11,81,82],{},"Response time measures how long your site takes to respond to each check. Most dashboards show an average, but the average alone can be misleading.",[11,84,85],{},"What actually matters:",[40,87,88,94,100],{},[43,89,90,93],{},[15,91,92],{},"Average response time",": The baseline. Under 500ms is solid for most sites.",[43,95,96,99],{},[15,97,98],{},"P95 \u002F P99 response time",": What the slowest 5% or 1% of requests look like. If your average is 200ms but your P95 is 4 seconds, your users are noticing.",[43,101,102,105],{},[15,103,104],{},"Trends over time",": A response time chart that slowly creeps upward — even by 50ms per week — is an early warning sign. Your database is growing, a cache is filling up, or a third-party dependency is slowing down.",[11,107,108,110,111,116],{},[15,109,74],{},": Set a slow response threshold. In ",[112,113,115],"a",{"href":114},"\u002Fdocs\u002Fsetting-up-monitor","Monitoristic",", you can define what \"slow\" means for each monitor. When response times cross that line, you get alerted before it becomes an outage.",[26,118,120],{"id":119},"incident-timeline","Incident Timeline",[11,122,123],{},"The incident timeline is where the real story lives. Each entry shows:",[40,125,126,132,138,144],{},[43,127,128,131],{},[15,129,130],{},"When the outage started",": The exact timestamp of the first failed check",[43,133,134,137],{},[15,135,136],{},"How long it lasted",": Duration from first failure to confirmed recovery",[43,139,140,143],{},[15,141,142],{},"What happened",": Status codes, timeout errors, DNS failures — the raw evidence",[43,145,146,149],{},[15,147,148],{},"When it was resolved",": The timestamp of the first successful check after the outage",[11,151,152],{},"Patterns in the timeline tell you more than any single metric:",[40,154,155,161,167,173],{},[43,156,157,160],{},[15,158,159],{},"Same time every day?"," Probably a cron job, backup, or deployment window",[43,162,163,166],{},[15,164,165],{},"Always the same duration?"," Could be an auto-scaling delay or a service restart cycle",[43,168,169,172],{},[15,170,171],{},"Clustered around deploys?"," Your deployment process needs a health check gate",[43,174,175,178],{},[15,176,177],{},"Random and unpredictable?"," Infrastructure instability — check your hosting provider's status history",[11,180,181,183],{},[15,182,74],{},": Look at the last 30 days of incidents. If you see a pattern, that pattern is your highest-priority fix.",[26,185,187],{"id":186},"check-interval-and-its-effect-on-data","Check Interval and Its Effect on Data",[11,189,190],{},"Your check interval directly affects the accuracy of your report.",[40,192,193,199,205],{},[43,194,195,198],{},[15,196,197],{},"5-minute checks",": Good for general awareness. You'll catch outages longer than 5 minutes reliably. Short blips (under 2 minutes) might be missed entirely.",[43,200,201,204],{},[15,202,203],{},"2-minute checks",": Catches most incidents. Good balance for production APIs and customer-facing sites.",[43,206,207,210],{},[15,208,209],{},"1-minute checks",": Near real-time detection. Essential for high-traffic or revenue-critical services.",[11,212,213,214,217],{},"A report based on 5-minute checks showing 100% uptime doesn't mean there were zero issues — it means there were no issues lasting longer than 5 minutes. If your ",[112,215,216],{"href":114},"check interval"," is longer than your typical outage duration, your report looks better than reality.",[11,219,220,222],{},[15,221,74],{},": Match your check interval to how quickly you need to know about problems. Revenue-critical? Go with 1-minute or 2-minute checks.",[26,224,226],{"id":225},"what-to-actually-do-with-your-report","What to Actually Do With Your Report",[11,228,229],{},"Reading the numbers is step one. Here's how to turn them into action:",[231,232,233,239,245,256,262],"ol",{},[43,234,235,238],{},[15,236,237],{},"Set a baseline",": Know your normal uptime percentage and average response time. You can't spot degradation if you don't know what healthy looks like.",[43,240,241,244],{},[15,242,243],{},"Review weekly",": A quick weekly glance at your dashboard catches trends before they become incidents. Don't wait for an outage to look at your data.",[43,246,247,250,251,255],{},[15,248,249],{},"Share with your team",": A ",[112,252,254],{"href":253},"\u002Fblog\u002Fhow-to-set-up-a-public-status-page","public status page"," keeps your users informed. An internal review keeps your engineering team accountable.",[43,257,258,261],{},[15,259,260],{},"Focus on patterns, not individual events",": One outage is an incident. The same outage three weeks in a row is a systemic problem.",[43,263,264,267,268,272],{},[15,265,266],{},"Use alerts, not dashboards",": Dashboards are for review. ",[112,269,271],{"href":270},"\u002Fdocs\u002Ftelegram","Alerts"," are for action. If you're manually checking your dashboard to find out about downtime, your monitoring setup is incomplete.",[26,274,276],{"id":275},"the-report-is-a-tool-not-a-score","The Report Is a Tool, Not a Score",[11,278,279],{},"It's tempting to treat uptime percentage as a grade. But 99.9% isn't an A+ — it's a data point. The value of an uptime report isn't the number at the top. It's the patterns it reveals, the incidents it documents, and the decisions it enables.",[11,281,282],{},"Read it regularly. Share it with your team. Act on what it tells you.",{"title":284,"searchDepth":285,"depth":285,"links":286},"",2,[287,288,289,290,291,292],{"id":28,"depth":285,"text":29},{"id":78,"depth":285,"text":79},{"id":119,"depth":285,"text":120},{"id":186,"depth":285,"text":187},{"id":225,"depth":285,"text":226},{"id":275,"depth":285,"text":276},"Guide","2026-05-09","Uptime percentages, response times, incident timelines — learn what each metric in an uptime report means and how to use them to make better decisions.","md",[298,301,304,307],{"q":299,"a":300},"What does 99.9% uptime actually mean?","99.9% uptime means your site was down for roughly 8 hours and 46 minutes over the course of a year, or about 43 minutes per month. It sounds high, but those 43 minutes can cost real revenue depending on when they happen.",{"q":302,"a":303},"What's a good average response time?","For most websites, under 500ms is good and under 200ms is excellent. What matters more than the absolute number is consistency — a site that averages 300ms but spikes to 5 seconds under load has a performance problem, even if the average looks fine.",{"q":305,"a":306},"How far back should I look at uptime data?","At least 30 days for a meaningful picture. A single day can look perfect or terrible depending on timing. Longer windows (60–90 days) reveal patterns — recurring outages at specific times, gradual performance degradation, or the impact of deployments.",{"q":308,"a":309},"Is a single downtime incident always bad?","Not necessarily. A 30-second blip during a deployment is very different from a 45-minute outage during peak traffic. Context matters — when it happened, how many users were affected, and how quickly it was resolved tell you more than the raw number.",{"src":311,"alt":312},"\u002Fblog\u002Fblog-how-to-read-an-uptime-report.webp","Dashboard showing uptime percentage, response time chart, and incident timeline",{},true,"\u002Fblog\u002Fhow-to-read-an-uptime-report",5,{"title":5,"description":295},"blog\u002Fhow-to-read-an-uptime-report","q-0cOMJnveCkbBopzsXcWLC82YVPnqbmO5vwP-p5Gck",1778462015867]