Skip to article
Monitoring and Observability SRE and reliability

Error budget

An error budget is the amount of unreliability a service can consume while still meeting its service level objective over a defined measurement window.

Source: Microsoft Learn - Scalable cloud applications and site reliability engineering Reviewed 2026-05-14

Exam trap
Assuming a matching display name proves the right tenant, subscription, project, table, endpoint, or event subscription was checked.
Production check
Can you identify the exact owner, scope, resource ID, environment, and downstream dependency without guessing?
Practice this topic Microsoft Learn
Article details and learning context
Aliases
error budget
Difficulty
intermediate
CLI mappings
4
Last verified
2026-05-14
Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

Error budget is the allowed amount of failure, downtime, or bad user experience a workload can have before it violates its agreed reliability target. In Azure, it usually appears when product and platform teams need a practical way to balance feature delivery against reliability work using measured service level objectives. Teams use it to define an SLO, measure good and bad events, calculate remaining budget over a window, and decide when to slow releases or invest in reliability.

Why it matters

Error budget matters because it converts reliability from an emotional debate into a measured tradeoff between shipping features and protecting user trust. Without it, teams often continue releasing while users experience poor reliability, over-invest in unnecessary resilience, or argue about incidents without a shared numeric target. A strong implementation gives architects a clear decision point, gives operators measurable evidence, and gives security reviewers proof that the intended boundary or workflow is real. It also prevents confusing this term with adjacent Azure concepts that look similar but solve a different problem. That shared vocabulary is important when support, compliance, platform engineering, and application owners all need to reason about the same production behavior.

Technical context

Technically, Error budget sits in Azure Monitor, Application Insights, Log Analytics, availability tests, metric alerts, action groups, incident management, and workload reliability reviews. It depends on instrumented applications, clear user journeys, agreed SLOs, reliable telemetry, alert rules, ownership, and a decision process tied to releases and is usually validated through Azure Monitor metrics, Application Insights queries, workbooks, alert rules, incident dashboards, and release governance records. The configuration connects to SLOs, error rates, availability tests, latency objectives, incident response, change freeze decisions, and reliability improvement backlogs.

Exam context

Compare with

Azure budget Budget alert SLA

Where it is used

Where you see it

  1. In SRE dashboards, an error budget appears as remaining allowed failures or downtime for a service level objective during a measurement window during production review and support triage.
  2. In release governance, it appears when teams pause risky launches because recent incidents consumed too much of the reliability budget during production review and support triage.
  3. In Azure Monitor, it appears through queries, workbooks, burn-rate alerts, availability tests, and Application Insights metrics for critical user journeys during production review and support triage.

Common situations

  • Use Error budget when production behavior depends on the concept being configured, monitored, or governed correctly.
  • Decide whether a team should prioritize features or reliability improvements.
  • Trigger release gates when recent incidents consume too much reliability budget.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Error budget in action for education technology Scenario, objectives, solution, measured impact, and takeaway.
Scenario

Graphic Design Institute, a education technology organization, needed to solve a production challenge: students experienced intermittent login delays, but release teams lacked a shared rule for pausing feature deployments. The architecture team had to improve the workflow without weakening governance or disrupting users.

Goals
  • Define a 99.9 percent login SLO
  • Calculate remaining error budget weekly
  • Pause risky releases during high burn
  • Reduce reliability debates in change meetings
Approach using Error budget

The platform team defined good login events in Application Insights and measured failures plus slow responses over a rolling thirty-day window. An Azure Monitor workbook displayed error-budget remaining, burn rate, and recent incidents. Release managers used the dashboard in deployment reviews: if budget burn exceeded the agreed threshold, only reliability fixes could proceed. Alerts notified the identity squad when burn accelerated after a dependency change. The implementation record captured accountable owners, rollback steps, monitoring thresholds, test evidence, and the exact checks operators would use before changing Error budget in production.

Potential outcomes
  • Change meetings moved from opinion to measured SLO evidence
  • Login incidents dropped by 33 percent over the term
  • Two feature releases were paused before compounding user impact
  • The team recovered the budget within three weeks
What to learn

An error budget helps teams make disciplined release decisions before reliability damage becomes normal.

Scenario 02 Error budget in action for financial services Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A. Datum Payments, a financial services organization, needed to solve a production challenge: payment API owners overbuilt every component because they had no measured tolerance for short failures. The architecture team had to improve the workflow without weakening governance or disrupting users.

Goals
  • Set journey-based reliability targets
  • Prioritize resilience work by budget burn
  • Reduce unnecessary premium capacity spend
  • Keep compliance evidence for incidents
Approach using Error budget

Architects defined an error budget around successful authorization requests, not raw VM uptime. Application Insights queries measured bad events, while Azure Monitor alerts detected fast burn during processor outages. When the budget had healthy margin, teams shipped approved features; when burn increased, the backlog shifted to retry tuning, dependency circuit breakers, and regional failover tests. Finance reviewed cost changes against error-budget evidence rather than blanket resilience requests. The implementation record captured accountable owners, rollback steps, monitoring thresholds, test evidence, and the exact checks operators would use before changing Error budget in production. Security, application, and platform teams reviewed the design together so identity, network, logging, cost, and lifecycle controls matched the Error budget operating model.

Potential outcomes
  • Premium capacity expansion was reduced by 18 percent
  • Authorization reliability stayed within the SLO window
  • Incident reviews included clear budget consumption numbers
  • Reliability work focused on the top two bad-event causes
What to learn

Error budgets prevent both reckless shipping and expensive reliability work that does not improve user outcomes.

Scenario 03 Error budget in action for transportation Scenario, objectives, solution, measured impact, and takeaway.
Scenario

Metro North Apps, a transportation organization, needed to solve a production challenge: a commuter information app needed one rule for deciding when incidents should block new timetable features. The architecture team had to improve the workflow without weakening governance or disrupting users.

Goals
  • Measure rider-facing availability
  • Detect fast budget burn during peak travel
  • Connect incidents to release policy
  • Improve executive reliability reporting
Approach using Error budget

The operations team mapped critical flows such as trip search, arrival prediction, and service alerts to SLOs. Azure Monitor workbooks calculated error-budget remaining from availability tests, request success, and latency thresholds. During severe weather, burn-rate alerts escalated to the on-call team and automatically added evidence to incident reviews. Product managers accepted a policy that feature deployments paused when the commuter-facing budget fell below the agreed threshold. The implementation record captured accountable owners, rollback steps, monitoring thresholds, test evidence, and the exact checks operators would use before changing Error budget in production. Security, application, and platform teams reviewed the design together so identity, network, logging, cost, and lifecycle controls matched the Error budget operating model.

Potential outcomes
  • Peak-period incident response started 22 minutes faster
  • Executive reports showed budget remaining by journey
  • Three low-priority releases were deferred during severe weather
  • Rider complaint volume fell after alert thresholds were tuned
What to learn

Error budgets make reliability visible to both engineers and business owners.

Azure CLI

CLI checks for Error budget turn portal assumptions into repeatable evidence. Start with read-only show, list, query, or metrics commands, capture the exact scope, and compare output with source control and runbooks. Mutating commands should run only through an approved change because the wrong subscription, project, table, event subscription, or resource can change customer-facing behavior.

Useful for

  • Confirm the live resource, setting, subscription, or project that owns Error budget before a production change.
  • Collect repeatable evidence for Error budget during support, audit, cost, reliability, or security review.
  • Run approved update commands only after validating scope, owner, rollback path, and expected downstream impact.

Before you run a command

  • Run az account show and confirm the tenant, subscription, environment, and signed-in identity before collecting evidence.
  • Confirm the exact resource group, resource name, deployment name, owner, and ticket before running mutating commands.
  • Use read-only commands first, save sanitized JSON output, and compare it with source control, runbooks, and approved design notes.

What the output tells you

  • Whether the resource, deployment, identity, event subscription, tag, table entity, or monitored component exists at the expected scope.
  • Which IDs, names, states, filters, tags, headers, metrics, timestamps, and linked resources explain the current production behavior.
  • Whether follow-up work should focus on access, schema, routing, monitoring, retry behavior, cost allocation, or application configuration.

Mapped commands

Error budget operational checks

direct 
az monitor metrics list --resource <resource-id> --metric <availability-or-failure-metric> --interval PT1H
az monitor metricsdiscoverMonitoring and Observability
read-only Microsoft Learn 
az monitor app-insights query --app <app-insights-name> --analytics-query "requests | summarize total=count(), failed=countif(success == false) by bin(timestamp, 1h)"
az monitor app-insightsdiscoverMonitoring and Observability
read-only Microsoft Learn 
az monitor metrics alert list --resource-group <resource-group> --output table
az monitor metrics alertdiscoverMonitoring and Observability
read-only Microsoft Learn 
az resource show --ids <workbook-or-alert-resource-id>
az resourcediscoverMonitoring and Observability
read-only Microsoft Learn

Architecture context

Error budget belongs to Monitoring and Observability architecture decisions where identity, data handling, monitoring, reliability, cost, and operations must be designed together instead of patched after deployment.

Security
Security for Error budget starts with telemetry access, incident data sensitivity, change approval evidence, privileged release overrides, and avoiding dashboards that expose customer or regulated data. Review the control at the Azure scope where it is configured, not only in a diagram. Confirm who can create, update, disable, or delete it and whether those actions are visible in logs. Sensitive data, secrets, identities, endpoints, and telemetry should be treated as part of one design. Prefer least privilege, managed identity where appropriate, private access where required, and documented approvals for changes that affect production users or regulated data. Operators should document ownership, scope, dependency health, evidence, and rollback before changing production behavior.
Cost
Cost for Error budget is driven by reliability investment timing, over-engineering avoidance, monitoring ingestion, duplicate alerts, incident labor, and targeted improvements when budget burn proves user impact. The direct Azure charge may be only part of the total; operator time, reprocessing, duplicate environments, support tickets, and audit preparation can be larger than the visible line item. Teams should estimate steady-state usage, rollout spikes, test activity, and failure-driven retries. They should tag owners and environments so costs can be explained later. A practical review asks whether the design prevents waste, avoids unnecessary duplication, and makes cleanup easy when the workload ends.
Reliability
Reliability for Error budget depends on SLO definition, measurement quality, alert thresholds, burn-rate detection, incident classification, and release decisions based on remaining budget. Operators need a known-good baseline, a way to detect drift, and a rollback or retry path that has been rehearsed before an emergency. Dependencies should be named explicitly so responders know which service, identity, schema, quota, endpoint, or configuration can block the workload. Test failure modes, not only happy paths, because many Azure issues appear as partial degradation. Reliable use means the feature keeps doing the expected job after releases, scaling, rotation, and regional events. Operators should document ownership, scope, dependency health, evidence, and rollback before changing production behavior.
Performance
Performance for Error budget depends on latency-based bad events, slow dependency detection, p95 and p99 thresholds, availability-test realism, telemetry sampling, and workload behavior under peak traffic. The useful measurement is usually not just average latency; teams should inspect tail latency, throughput, throttling, retry behavior, dependency response time, and user-visible outcomes. Testing should use realistic inputs and production-like scale because small tests hide bottlenecks. Operators need dashboards that separate platform behavior, application code, network paths, and downstream dependencies. When performance changes after a release, the team should be able to compare old and new configuration quickly. Operators should document ownership, scope, dependency health, evidence, and rollback before changing production behavior.
Operations
Operations for Error budget should focus on dashboard ownership, query maintenance, incident review cadence, release gate rules, escalation paths, and documentation of budget consumption decisions. The term should appear in runbooks with the resource name, owner, environment, normal state, and approved change procedure. Operators should know which portal page, CLI command, metric, log, or REST response proves current state. Alerts should be actionable instead of only proving something exists. Good operations include periodic review, cleanup of stale configuration, evidence capture for audits, and a clear escalation path when application, platform, and security teams share ownership. Operators should document ownership, scope, dependency health, evidence, and rollback before changing production behavior.

Common mistakes

  • Assuming a matching display name proves the right tenant, subscription, project, table, endpoint, or event subscription was checked.
  • Running an update before capturing read-only evidence, owner approval, expected post-change behavior, and rollback instructions.
  • Ignoring related identity, network, monitoring, schema, partitioning, and lifecycle dependencies that make the term work in production.