How to calculate your error budget from your error tracker (no SRE team required)

You're looking at your error tracker. 1,242 events in the last 24 hours. Is that a disaster, or just a Tuesday? If you're a developer at a growing startup, you probably check your dashboard every morning with a sense of low-grade dread. You see a spike in the graph, your heart rate climbs, and you start digging through stack traces to see if the sky is falling. But without an error budget, every spike feels like a crisis and every quiet period feels like a lie. We're going to stop guessing and start calculating exactly how much "unreliability" your business can actually afford.

Why raw error counts are a vanity metric

In the world of observability, we talk a lot about "vanity metrics." Usually, this refers to things like total signups or page views—numbers that go up and to the right but don't actually tell you if the business is healthy. In engineering, "Total Error Count" is the ultimate vanity metric. It's a number that exists in a vacuum, stripped of the context that makes it meaningful.

The denominator problem: Errors vs. Total Throughput

Imagine you have two applications. App A reported 100 errors yesterday. App B reported 1,000 errors. Which one is in more trouble? Most developers would instinctively point to App B. But if App A only handled 1,000 total requests, it has a 10% failure rate. That's a catastrophe. If App B handled 1,000,000 requests, it has a 0.1% failure rate. That's a typical, perhaps even "healthy," Tuesday.

Without the denominator—your total traffic—the numerator (the error count) is just noise. Your error tracker is great at showing you the "what" and the "where," but it's terrible at showing you the "how much." To know if 1,000 errors is a problem, you have to know if those errors represent a significant chunk of your users' experience or just a tiny fraction of the background radiation of the internet.

Why a 0-error goal is a recipe for burnout

The most dangerous goal an engineering team can set is "zero errors." It sounds noble, but it's technically impossible and culturally toxic. The internet is a messy place. Clients lose connectivity mid-request. Users have weird browser extensions that break your JavaScript. Third-party APIs go down. If your goal is zero, you will spend 80% of your time chasing ghosts that you can't control, which means you aren't shipping features that actually provide value.

An error budget acknowledges that failure is inevitable. It gives you a way to say, "We expect some things to break, and as long as they break less than X% of the time, we're okay with that." This shifts the conversation from a binary "Is it broken?" to a nuanced "Is it reliably enough?"

SLOs and SLIs for the rest of us

Site Reliability Engineering (SRE) literature is often dense and aimed at companies with thousands of engineers. But the core concepts—SLIs, SLOs, and Error Budgets—are remarkably simple when you strip away the jargon.

The Service Level Indicator (SLI): Your error rate

The SLI is just the measurement itself. In our case, the most common SLI is the ratio of successful requests to total requests. If you handle 1,000,000 requests and 1,000 of them return a 500 error, your SLI is 99.9% success. It's the "fact on the ground."

The Service Level Objective (SLO): Your target

The SLO is the goal you set for that indicator. It's the line in the sand. You might decide that 99.9% availability is "good enough" for your API. This is a business decision, not just a technical one. If you're building a heart rate monitor, your SLO should be much higher than if you're building a social media app for cats.

The Error Budget: The inverse of your SLO

The Error Budget is simply 1 minus your SLO. If your SLO is 99.9%, your error budget is 0.1%. This is the amount of "unreliability" you are allowed to "spend" each month. You can spend it on buggy releases, infrastructure migrations, or unexpected outages. The goal isn't to have a 0% error rate; the goal is to not overspend your budget.

Here is how those "9s" translate into actual failure allowances per million requests:

• 99% SLO: 1% Error Budget (10,000 allowed failures per 1M requests)
• 99.5% SLO: 0.5% Error Budget (5,000 allowed failures per 1M requests)
• 99.9% SLO: 0.1% Error Budget (1,000 allowed failures per 1M requests)
• 99.99% SLO: 0.01% Error Budget (100 allowed failures per 1M requests)

The math of "9s" (Converting percentages to minutes)

Percentages are abstract. Minutes are real. When you tell a stakeholder that you have 99.9% availability, they might think that sounds low. But when you translate that into "43.8 minutes of downtime per month," it starts to sound quite impressive.

Why 99.99% is probably overkill for your SaaS

Every extra "nine" you add to your SLO increases the cost of maintenance exponentially. To move from 99.9% (43 minutes of downtime a month) to 99.99% (4 minutes of downtime a month), you usually have to re-architect your entire stack for multi-region redundancy and automated failover. For most B2B SaaS companies, the difference between 4 minutes and 40 minutes of monthly downtime is negligible to the customer, but the cost to the engineering team is enormous. Most startups should aim for 99.5% or 99.9% and stay there until they have a very good reason to change.

The "Downtime Budget" vs. the "Error Budget"

It's important to distinguish between total system downtime (the app is literally gone) and the error budget (some requests are failing). A system can be "up" but still consuming its error budget if a specific endpoint is throwing 500s. The error budget is a more granular and honest way to measure user pain than a simple "up/down" check.

Gathering your data: Errors and Denominators

To calculate your budget, you need two numbers: your total errors and your total requests. Most developers have the first number but struggle with the second.

Pulling "Total Events" from GlitchReplay or Sentry

If you use a tool like GlitchReplay, you already have your error count. Because GlitchReplay is Sentry-SDK compatible, you can just look at your dashboard for the total number of events received in a given window. One thing to watch out for is "grouping." You want the raw event count, not the number of "unique" issues, because every single error event represents a "failed request" in the eyes of a user.

Finding your "Total Requests"

This is your denominator. You can usually find this in your load balancer logs (Nginx, AWS ALB), your CDN (Cloudflare), or your hosting platform (Vercel). If you're running on a modern stack like Cloudflare Workers with D1, you might pull your request counts directly from a logging table. Here is a simple SQL snippet you might use if you're storing request metadata:

SELECT 
    count(*) as total_requests,
    sum(case when status >= 500 then 1 else 0 end) as total_errors
FROM request_logs 
WHERE timestamp > date('now', '-30 days');

If you don't have a database of logs, you can often get a quick estimate from your analytics provider or by using a curl command against your infrastructure API. For example, if you use Nginx, a quick awk script on your access logs can give you the breakdown:

awk '{print $9}' access.log | sort | uniq -c

Normalizing for PII-scrubbed or sampled data

If you use heavy sampling in your error tracker (e.g., you only send 10% of errors to save money), you need to multiply your error count back up before doing the math. This is one reason why GlitchReplay's flat-rate pricing is helpful—because there are no per-event charges, you don't have to sample your data, which means your error budget math stays accurate and simple.

Calculating your Monthly Error Budget (The Manual Way)

Let's walk through the math for a hypothetical startup called "Checklist App."

Step 1: Define your target SLO

The team at Checklist App decides that 99.9% is their target. This means they are aiming for "three nines."

Step 2: Calculate total allowed errors

Checklist App handles 5,000,000 requests per month. To find their allowed errors, they multiply their total traffic by their error budget (0.1%):

5,000,000 * 0.001 = 5,000

Checklist App is "allowed" to have 5,000 errors per month before they violate their SLO.

Step 3: Compare against actual error count

They check their error tracker and see they had 1,242 errors in the last 30 days.
5,000 (Budget) - 1,242 (Spent) = 3,758 (Remaining)

They have used roughly 25% of their budget. They are in great shape. They can continue shipping features with high velocity.

Using the GlitchReplay Error Budget Calculator

If you don't want to do this math on a napkin every month, we built a tool to do it for you. The GlitchReplay Error Budget Calculator is the "easy button" for this workflow.

You simply input your estimated monthly traffic and your current error count, and it will visualize your "Burn Rate." The burn rate is a crucial concept: it tells you how fast you are consuming your budget. If you have 30 days in a month and you spend 50% of your budget in the first 2 days, your burn rate is too high, and you are guaranteed to blow your SLO by the end of the week.

The tool also helps you visualize your monthly downtime allowance. Seeing that you have "43 minutes left" is often much more motivating for a team than seeing a percentage like "0.08% left." When you find a bug that is eating your budget, you can use Session Replay to see exactly how that error impacted the user, allowing you to fix it before the budget is completely exhausted.

Turning math into policy: The "Error Budget Policy"

The math is the easy part. The hard part is the human element: what do you actually do when the budget is gone? If you have an SLO but no policy for what happens when you break it, you don't actually have an SLO—you just have a sad chart.

The "Code Freeze" trigger

The most common error budget policy is simple: if the budget is exhausted, the team stops shipping new features and spends 100% of their cycles on stability and bug fixes. This is often called a "Code Freeze," though it's more of a "Feature Freeze." You are still shipping code, but the only code allowed through the pipeline is code that directly addresses the reliability issues that caused the budget to blow.

Negotiating with stakeholders

This is where the error budget becomes a powerful shield for engineers. Without it, when a PM asks why the new feature is delayed, the engineer says, "The app feels buggy." That's a weak, subjective argument. With an error budget, the engineer says, "We have consumed 110% of our monthly error budget. According to our agreed-upon policy, we have triggered a feature freeze until we get the error rate back under 0.1%."

This moves the conversation from "Engineers are being perfectionists" to "We are adhering to our reliability contract."

Incentivizing stability over velocity

When you have an error budget, "shipping fast" and "shipping stable code" are no longer at odds. The team is incentivized to build better testing and automated rollbacks because they know that a bad release will eat their budget and stop them from working on the "fun" features later in the month. It creates a self-regulating system where the team naturally balances speed and quality.

A simple Error Budget Policy template

If you want to implement this today, you don't need a 20-page document. Start with something this simple:

Error Budget Policy for Team X
1. Our SLO is 99.9% success for all API requests.
2. This gives us an Error Budget of 0.1% (1,000 errors per 1M requests).
3. If at any point our 30-day rolling error budget is exhausted (< 0% remaining), the team will pause all non-critical feature work.
4. The team will prioritize root-cause analysis and fixes for the top 3 error sources until the budget is back in the green.
5. This policy can only be overridden by the CTO in the case of a business-critical emergency.

Stop guessing your uptime and stop letting raw error counts dictate your stress levels. Use our Free Error Budget Calculator to see how many "9s" your app actually has, define your policy, and start shipping with the confidence that you know exactly how much "breaking things" you can actually afford.