proomt

Search

Search posts, papers, and topics

All posts

Hacker News front pageJim Nielsen2 min readintro

Can we stop with the uptime percentages?

Read on jim-nielsen.comHN 144·112 comments

Summary

This article argues that uptime percentages are a poor public interface for communicating service reliability because their non-linear nature is not intuitive to non-infrastructure people. It proposes showing absolute downtime (e.g., hours affected) alongside percentages for better clarity for a general audience.

  • Uptime percentages near 100% are non-linear; 99.9% vs 99.99% represents a 10x difference in downtime.
  • This non-linearity makes uptime percentages a poor interface for general users on public status pages.
  • Infrastructure teams understand 'nines' intuitively, but the broader public does not.
  • Suggests displaying absolute downtime (e.g., '12 hours affected in the last 30 days') for better user comprehension.

This matters for anyone designing or consuming public status pages, as it highlights a common communication failure and offers a practical improvement for user understanding.

6/10
devopsapi designobservabilitycommunicationux

Related reading

  1. Why Releasing Software as an Application Beats Deploying Components

    This article argues that independent microservice deployments, while seemingly fast, often lead to complex and fragile releases due to environment drift and implicit dependencies. It advocates for "application-level releasing," where a consistent, validated snapshot of interdependent components is promoted together across environments to restore predictability and stability.

    Codeshipcloudbees.com5 min

  3. What Sun got wrong

    The author reflects on Sun Microsystems, arguing that despite strong technology, Sun failed because it grew bored with the mechanics of running a business—illustrated by a 2005 startup’s experience where Sun’s sales response was slow and mismatched while Dell’s personal rep closed the deal quickly. The story warns engineers and founders that operational discipline is as critical as technical visi…

    Lobstersdtrace.org3 minHN478263lobste.rs86

  4. Worker Backpressure (Part 1)

    Canva added a lightweight, local backpressure loop to its queue worker library that monitors per‑message success/failure, computes a backoff factor against a configurable failure‑rate set‑point, and throttles the worker’s concurrency. In two real incidents the mechanism kept failure rates under 2 % fleet‑wide, limited DLQ growth to a handful of messages, and maintained throughput without manual i…

    Canvacanva.dev10 min

  5. Best practices for handling cloud reliability incidents

    The article outlines a structured Verify→Investigate→Report→Resolve→Review workflow for GCP reliability incidents and stresses pre‑incident preparation across design, data, playbooks, and training. It lists concrete tools (Cloud Logging, Service Health, Gemini Assist) and reporting steps to help engineers reduce outage impact.

    Google Cloud Bloggoogle.com11 min