DevOps & SRE Tools
16 free, no-signup utilities for Site Reliability Engineers, DevOps teams, and platform engineers. SLOs, error budgets, burn-rate alerts, observability cost, Kubernetes right-sizing, postmortems and runbooks — all in your browser.
SLOs & Availability
Define realistic service-level objectives, measure how fast you are spending the error budget, and understand the availability ceiling imposed by your dependency graph.
SLA & Uptime Calculator
Calculate the maximum allowed downtime for any SLA percentage. See exactly how much downtime 99.9%, 99.95%, 99.99%, or 99.999% allows per day, week, month, quarter, and year.
Error Budget Calculator
Track SLO burn in real time. See remaining error budget, burn rate vs ideal pace, and projected end-of-period SLO based on incidents so far.
Burn Rate Calculator
Generate multi-window burn rate alert thresholds for any SLO using the canonical Google SRE Workbook windows. Includes a copy-paste Prometheus alert rule.
Composite Availability Calculator
Calculate the compound availability of a service that depends on multiple upstream services. Model serial chains and redundancy to see your real SLA ceiling and worst offender.
Cost & Sizing
Quantify the dollar cost of downtime, estimate observability spend before signing the contract, and right-size Kubernetes pods so you stop paying for capacity you do not use.
Incident Cost Calculator
Estimate the true business cost of downtime. Factor in revenue loss, engineer time, customer impact, and reputation damage to build the ROI case for reliability investments.
Datadog Cost Estimator
Estimate your monthly Datadog bill across hosts, APM, custom metrics, logs, synthetics, and RUM. Useful as a sanity check before procurement conversations.
Kubernetes Pod Right-Sizer
Calculate CPU and memory requests and limits for Kubernetes pods from average and p95 utilization. Generates a complete resources YAML block ready to paste into your Deployment.
Observability
Catch the high-cardinality label that is OOM-killing your Prometheus, lint your alert rules against best practices, and split a latency budget across every layer of your stack.
Prometheus Cardinality Estimator
Estimate Prometheus series count, head-block memory, and disk usage from a metric name and label dimensions. Spot the high-cardinality offender before it OOM-kills your Prometheus.
Prometheus Config Linter
Lint Prometheus alert rules, recording rules, and scrape configs against best practices. Catches missing for: clauses, severity labels, naming violations, and more.
Latency Budget Allocator
Allocate an end-to-end latency target across frontend, network, application, database, and external APIs. Visual stacked-bar tool that frames the architecture conversation.
Incident Response
Measure the metrics that actually matter, generate the postmortem and runbook templates that on-call engineers actually want to read, and score your alerting hygiene before the next bad week.
MTTR / MTTA / MTBF Calculator
Calculate Mean Time to Recovery, Mean Time to Acknowledge, and Mean Time Between Failures from your incident data. Compare against industry benchmarks.
Postmortem Template Generator
Generate a complete blameless postmortem template in Markdown. Timeline, 5 Whys, impact, detection / response metrics, action items, lessons learned. Copy or download.
Runbook Generator
Generate a complete on-call runbook in Markdown. Symptoms, diagnostic commands, mitigation steps, rollback procedure, escalation path, and dashboards — all from one form.
Alert Noise Score
Score your alerting hygiene from 0-100 across noise rate, flap rate, and after-hours skew. Get prioritized recommendations to cut alert fatigue and reclaim your on-call rotation.
On-Call Fairness Analyzer
Analyze on-call rotation fairness across your team. See pages per engineer, weekend distribution, and a weighted burnout score that flags overloaded teammates.
Utilities
Everyday quality-of-life tools every SRE eventually wants on hand.
Automate your incident response
Reduce MTTR by 90% with AI-powered root cause analysis. Free to start.
Built by SREs, for SREs
Every team running production systems eventually rebuilds the same utilities in a spreadsheet or scratch script: how much downtime does a 99.95% SLA actually allow each month? What did that two-hour outage cost the business? Is our 47-minute MTTR good or bad? Is this Prometheus rule going to flap? We built these tools so you can stop re-deriving the same answers and get back to the work that actually moves reliability forward.
Each tool runs entirely in your browser. There is no signup, no email gate, no logging of your inputs — you can audit the network tab and you will see nothing leaves the page. Link directly to any tool from your runbooks, onboarding docs, or SRE handbook.
When to use which tool
Reliability engineering tasks usually combine several of these tools. Here are the most common workflows we see in the wild.
Defining a new SLO from scratch
- Use the SLA & Uptime Calculator to translate business expectations into a concrete percentage.
- Use the Composite Availability Calculator to verify the target is achievable given your dependencies.
- Use the Burn Rate Calculator to derive the multi-window alert thresholds you will deploy.
Responding to a live incident
- Open the matching runbook (or generate one with the Runbook Generator if it does not exist).
- After resolution, run the MTTR Calculator with the incident data to see how you compare to last quarter.
- Generate a blameless postmortem with the Postmortem Template Generator.
Reducing observability cost
- Use the Datadog Cost Estimator to model the bill against current usage.
- Run the Prometheus Cardinality Estimator on your top metrics to find the high-cardinality offenders.
- Lint your rule files with the Prometheus Config Linter to catch flapping alerts before they ship.
Reclaiming an on-call rotation
- Run the Alert Noise Score to quantify current alerting hygiene.
- Use the On-Call Fairness Analyzer to spot rotation imbalance and burnout signals.
- Refine alert rules through the Burn Rate Calculator so on-call only fires on genuine SLO breaches.
SRE & DevOps Glossary
Terms and acronyms that show up across the tools above. Bookmark this section — many of these come up in every SLO review.
- SLI— Service Level Indicator
- A measurable signal of service quality — e.g., the fraction of HTTP requests that return successfully, or the fraction faster than 300ms.
- SLO— Service Level Objective
- A target for an SLI over a window — e.g., "99.9% of requests succeed over 30 days". The internal commitment your team makes.
- SLA— Service Level Agreement
- A contractually-binding promise to customers, usually with financial penalties (SLA credits) if you miss it. SLAs are typically set below SLOs to leave operational headroom.
- Error budget
- The maximum amount of unreliability allowed before violating the SLO. For 99.9% over 30 days, the error budget is 43 minutes 12 seconds of allowed downtime.
- Burn rate
- How fast you are consuming the error budget vs the ideal pace. 1× = on track, 2× = will exhaust budget in half the period, 14.4× = consuming 2% of monthly budget per hour.
- MTTR— Mean Time to Recovery
- Average time from incident start to full service restoration. The single most-tracked reliability metric.
- MTTA— Mean Time to Acknowledge
- Average time from alert firing to a human acknowledging it. Measures alert routing and on-call responsiveness.
- MTTD— Mean Time to Detect
- Average time from incident start to the team becoming aware (alert fires, customer report, manual observation).
- MTBF— Mean Time Between Failures
- Average time between successive incidents. Measures system reliability rather than response speed.
- Cardinality
- In Prometheus, the total number of unique time series for a metric. Calculated as the product of unique values across all labels — high cardinality is the #1 cause of Prometheus OOMs.
- Recording rule
- A precomputed PromQL expression saved as a metric. Used to make expensive aggregations instantly queryable. Convention: <level>:<metric>:<operation>.
- Multi-window burn-rate alert
- An alert that fires only when both a long window (e.g., 1h) and a short window (e.g., 5m) exceed a burn-rate threshold. Filters flapping while keeping detection fast.
- QoS class— Quality of Service
- Kubernetes assigns each pod a class (Guaranteed, Burstable, BestEffort) based on requests/limits. Determines eviction priority under node pressure.
- OOMKill— Out-of-Memory Kill
- When a process exceeds its memory limit, the kernel terminates it. The most common preventable Kubernetes failure mode.
- eBPF— Extended Berkeley Packet Filter
- A kernel feature that lets safe programs run inside the Linux kernel. Used for zero-instrumentation network observability — see TCP latency, retransmits, and connection errors without touching application code.
- Blameless postmortem
- An incident review focused on systems and processes, not individuals. Premise: people act in good faith with the information they have, so "person X did Y" is never the root cause.
- 5 Whys
- A root-cause technique: keep asking "why did that happen?" until you reach a systemic cause. Most teams stop at the second why and miss the real driver.
- Runbook
- A short, action-oriented document for on-call: what the alert means, how to confirm, how to mitigate. Linked from the alert itself for 3-AM reachability.
- Toil
- Manual, repetitive, automatable work that scales linearly with the service. Google's SRE book defines it precisely; the cure is usually code.
- Flapping alert
- An alert that repeatedly fires and resolves on its own without action. Almost always means a missing for: clause or a too-tight threshold.
- Page
- An alert urgent enough to wake someone up. The opposite of a ticket. Rule of thumb: only page if doing nothing makes the situation materially worse.
- Canary deploy
- Releasing a new version to a small fraction of traffic first to detect regressions before full rollout. The most cost-effective deploy safety mechanism.
From utilities to automation
Utilities like these describe the problem. Reducing MTTR — actually moving from 91 minutes to 47 seconds — takes automation. Uptimes.ai is an AI SRE agent that lives inside your Kubernetes cluster, correlates alerts across Datadog, Prometheus, and PagerDuty, reasons over your service dependency graph using eBPF kernel-level visibility, and produces a root cause report in under three minutes. When automation can resolve the issue — common cases like CrashLoopBackOff, OOMKilled, deploy regressions — it does, with a full audit trail.
If your numbers from the MTTR Calculator are higher than you would like, that gap is exactly what we exist to close. See how Uptimes.ai works →