{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }} {{ badge.value }}
Paste one sample, drop one TXT/CSV/LOG file, or browse locally. Analysis runs in this browser. The address and shared links include your source.
{{ sourceMeta }}
{{ sourceStatus || 'Accepted forms include 500=12, 500,12, or ordinary access-log lines.' }}
Name the API or SLO slice represented by this status sample.
Enter the target success percentage used by this API SLO.
%
The observed traffic and failure ratios are projected across this SLO window.
days
This normalizes request and failure volume before the full-period projection.
hr
Define which eligible HTTP responses consume this API's error budget.
Standard keeps operational labels compact; detailed shows additional decimal places.
MetricValueOperational meaningCopy
{{ row.metric }}{{ row.value }}{{ row.note }}
StatusClassRequestsShareBudget roleCopy
{{ row.status }}{{ row.classLabel }}{{ formatInteger(row.count) }}{{ formatPercent(row.share_percent, percentDigits) }}{{ row.consumes_budget ? 'Consumes budget' : 'Allowed' }}
GuardrailReferenceCurrentActionCopy
{{ row.guardrail }}{{ row.reference }}{{ row.current }}{{ row.action }}

{{ chartLoading ? 'Loading chart…' : chartError }}

Error Budget Calculator Calculate SLO error-budget use from observed traffic, compare burn and policy gates, and estimate runway before a release decision.
Error Budget Burn Rate Calculator Calculate SLO error-budget burn rate and compare page or ticket thresholds, then estimate runway from the budget that remains.
SLO Burn Rate Alerts Generator Generate multi-window Prometheus SLO burn-rate alerts with budget math and routing labels, then review thresholds before loading the YAML.
HTTP Access Latency Log Analyzer Analyze NGINX, Apache, or ALB access logs locally for endpoint P95 and 5xx rates with clear parse-gap evidence and SLA findings.

A service can return thousands of successful responses and still be on course to miss its reliability target. The deciding question is not how many requests failed in isolation, but how the failed share compares with the failure allowance promised by the service level objective (SLO).

An availability SLO sets a successful-request target over a compliance period. A target of 99.9% leaves an error budget of 0.1% of eligible requests. That budget gives teams room for ordinary failure while making sustained unreliability visible. At one million eligible requests, 0.1% allows 1,000 budget-consuming responses; at ten thousand requests, it allows only ten.

Eligible request
A request included in the service level indicator (SLI), the measurement used to judge the SLO.
Budget-consuming response
A response that the service policy counts as unsuccessful.
Burn rate
The observed failure ratio divided by the sustainable failure ratio. A value of 1 means the budget is being spent at exactly the rate the full period permits.

HTTP status does not decide SLO eligibility by itself. Server failures in the 5xx class are common budget consumers, but teams may also count 429 responses, selected client errors, or edge-specific codes when those outcomes represent a failed user experience. The same traffic sample can therefore produce different burn rates under different policies.

Short observations are useful for incident triage, yet they are noisy. Low traffic, a deployment burst, retries, bots, maintenance, or a changed status policy can distort a projection. A burn-rate estimate should be compared with the production SLI over a representative window before it drives an alert or release decision.

How to Use This Tool:

Use one traffic slice whose request counts, duration, and status policy describe the same API or SLO.

  1. Enter the API name, availability SLO, compliance period, and elapsed hours covered by the sample.
  2. Define budget-consuming statuses with classes such as 5xx, exact codes such as 429, or inclusive ranges such as 500-599.
  3. Paste aggregated status counts or access-log lines. If parsing fails, use one status per line or a status-and-count pair such as 503=18.
  4. Check Observed error rate, Burn rate, and Projected budget used together. Confirm that the status evidence matches the intended policy before acting on the projection.

Interpreting Results:

A burn rate below 1 means the observed failure share is below the sustainable share for the SLO. A burn rate of 1 is exactly on pace, while a value above 1 would exhaust the budget if the same failure ratio continued through a comparable compliance period.

  • Healthy means projected budget use is below 70%.
  • Watch begins at 70% and remains below 100%.
  • Spent begins at 100%, including exactly 100%.

These labels summarize a straight-line projection, not a forecast of future traffic. Recheck the source window, request eligibility, and status policy against the monitoring system before treating a short sample as an SLO breach.

Technical Details:

Request-based error budgets compare the observed bad-event fraction with the fraction permitted by the SLO. The calculation aggregates every parsed status, applies the chosen status policy, and keeps full numeric precision until display formatting.

Formula Core

The permitted failure ratio is the distance from the SLO to 100%.

E=1−S

Burn rate compares the observed budget-consuming request ratio with that allowance.

B=FN÷E
SymbolMeaningUnit
SAvailability SLO expressed as a ratio, so 99.9% becomes 0.999ratio
ESustainable failure ratioratio
FRequests whose status matches the budget-consuming policyrequests
NTotal parsed requestsrequests
BBurn rateratio

Projected budget use is B × 100%. Request and failure volumes are scaled by 24 divided by the observed hours and then by the compliance days. That scaling changes projected event counts, but the projected percentage remains the burn rate expressed as a percentage because both volumes use the same factor.

Rule Core

Status input accepts aggregated pairs, named status fields, or ordinary access-log rows. Repeated codes are added together. A class token such as 5xx matches the full class, an exact code matches only that code, and a range includes both endpoints.

QuantityRule
Allowed bad requests in sampleN × E; this may be fractional because it is an allowance, not an observed count.
Sample budget deltaAllowed bad requests minus observed budget-consuming requests; a negative value means the sample overspent its proportional allowance.
Projected remaining eventsProjected budget events minus projected bad events; negative values represent projected overspend.
RunwayThe compliance days divided by burn rate, capped at the compliance period. Zero burn keeps the full period.

The SLO must be greater than 0% and less than 100%. Compliance periods accept 1 to 366 whole days, observed windows accept 0.25 to 8,760 hours, and uploaded or pasted sources are limited to 2 MiB.

Accuracy and Privacy Notes:

The projection assumes the sample's traffic rate and failure ratio continue unchanged. It does not account for seasonality, traffic growth, maintenance exclusions, retries, latency objectives, or a monitoring system's eligibility filters.

  • Status text and local files are processed in the browser and are not uploaded by this analysis.
  • Access logs may contain client addresses, paths, and tokens. Use the narrowest safe slice and remove secrets before sharing exported evidence.
  • Burn-rate alert policies often use several windows and thresholds. The 70% and 100% labels here describe this projection only.

References: