Decentralised News · Agentic Finance · Decision research
By Heath Muchena · Source review 2026-11-13 · Instrument version 1.0.0
What Matters
- An error budget measures failure against a declared service objective. It does not authorize trades, losses or policy breaches.
- Count eligible original events once, including failed outcomes, and compare recent activity with the same declared population.
- DN’s calculator separates budget consumption, recent burn rate and hard-stop evidence. Its examples are synthetic and it connects to no trading system.
DN Alpha Thesis
In a synthetic scenario, a trading agent completes 99.96% of a defined workload. Its dashboard looks healthy. Yet ten of the last two thousand tasks failed, and a separate incident involved an instruction outside the permitted account boundary. Should the operator continue changing the system, investigate a reliability problem or stop new exposure?
Those questions need separate evidence. A service-level objective, or SLO, defines a target for a measured service outcome. It can help a team decide when reliability work should take priority. A safety policy defines actions that the system must not take. A profitable strategy and a reliable service can still cross that boundary.
DN’s contribution is a small event-based calculator that keeps the two records separate. It shows how much of a chosen reliability allowance has been consumed and whether the recent failure ratio is worse than the longer-period ratio. It also preserves a reported hard stop or an unresolved safety review instead of letting a favourable percentage override it. This is an operational worksheet, not a live monitor, a recommended trading strategy or a permission to deploy.
DN Evidence Block
Primary sources reviewed on 13 November 2026: Google’s SRE guidance on implementing SLOs, burn-rate alerts, its example error-budget policy, and current Cloud Monitoring documentation. They establish service-reliability concepts and implementation considerations. They do not prescribe an acceptable hallucination rate for finance or a legal allowance for unauthorized transactions.
The equations below apply those concepts to reader-entered, original-event counts. The classification rules, safety separation and worked scenarios are DN editorial design. No exchange, agent or production failure rate was measured for this edition.
Original DN instrument · version 1.0.0
DN Error-Budget and Burn-Rate Calculator
Compare a declared original-event SLO with period and recent failures, keeping safety stops separate.
Enter your assumptions or load a labelled example. Required blank numbers stay missing; unknown evidence remains unknown. Use nonpersonal labels only. This instrument makes no network requests and uses no persistent browser storage.
Use your own inputs
No current result. Enter inputs or load an illustrative example.
User-entered local calculation, no telemetry verification or trading permission. Count caps: one billion original events per window. Targets support four decimal places in percent.
Choose the service outcome before choosing the percentage
Start with a sentence that another reviewer can test: “For each eligible reconciliation request, return an authoritative order-state result within the agreed deadline.” That is a different objective from “HTTP requests return successfully,” “the model produces valid JSON,” or “the strategy earns money.” Choose one outcome and retain its acceptance rule.
Google’s SLO guidance connects the objective to user experience and a policy agreed by the people responsible for the service. DN’s practical extension is to write the event boundary before collecting the attractive headline. A status endpoint can be available while its information is too old to support the task.
For an original-task objective, group retries under the task they are trying to complete. Five attempts are not five new satisfied customers. If the task meets its declared final deadline after a permitted retry, classify the final task according to that rule and retain retry cost separately. Do not move a missed deadline after seeing the result.
Keep hard stops outside the reliability allowance
Define a separate control path for events such as an unauthorized destination, an exceeded authority limit or an uncertain consequential order state. DN’s existing kill-switch guide distinguishes stopping new orders, cancelling working orders and reducing exposure. This calculator performs none of those actions.
| Question | Relevant evidence | What a good SLO result cannot establish |
|---|---|---|
| Did the service meet its outcome target? | Eligible original events, accepted results and deadlines | That every financial action was authorized |
| Did a hard boundary fail? | Authority, order-state and policy records | That unused reliability allowance excuses the incident |
| Should trading resume? | Incident investigation, reconciled state and the actual recovery policy | That a local worksheet has approved recovery |
Consider an invented incident in which one instruction attempts to move 20,000 reference units outside the approved destination set. Thousands of successful read requests cannot make that instruction permissible. Do not dilute the incident with a denominator of harmless reads, or multiply an uptime percentage by account balance to manufacture an expected-loss estimate.
Read the error budget in events, not dollars
Let N be eligible original events in a completed observation window, F the failed events, and s the chosen success target as a fraction. The event allowance is B = N × (1 − s). This follows the eligible-event formulation in Cloud Monitoring’s documentation.
Budget consumption is F ÷ B × 100%, when B is positive. Remaining allowance is B − F. A negative result means the recorded failures exceed the allowance. The tool keeps that negative result visible; it does not clamp the result into a reassuring range.
The allowance can be fractional even though failures are whole events. With 500 eligible events and a 99.9% target, the allowance is 0.5 failures. The largest whole failure count that still meets the target is zero. Rounding the allowance up to one would silently weaken the objective.
The calculation describes the entered observation window. It does not grant a fixed number of future failures: additional eligible events change an event-based denominator, and a rolling window also loses old observations as time moves forward.
A healthy period can hide a deteriorating recent window
Google’s burn-rate guidance normalizes the observed failure ratio by the failure ratio allowed by the target. For a recent window with n eligible events and f failures, the rate is (f ÷ n) ÷ (1 − s). A rate of one matches the target’s permitted failure ratio; a higher value means faster consumption relative to that target.
In DN’s fictional example, the longer window contains 100,000 events and 40 failures. At 99.9%, the allowance is 100 failures: 40% has been consumed and 60 failure equivalents remain. The period burn rate is 0.4.
The recent window contains 2,000 of those same events and ten of those same failures. Its failure ratio is 0.5%, producing a burn rate of five. Those ten recent failures consumed 10% of the longer window’s event allowance. The longer-period result and the recent warning describe different aspects of the same supplied data.
Five times the permitted failure ratio is not five times the financial risk. Nor does this worksheet predict a countdown to exhaustion. Such a forecast would need assumptions about future traffic, failure rates, window expiry and changing exposure.
Require the windows to describe the same population
The recent window must end at the same cutoff and sit inside the longer window. Use the same service version boundary, eligible task definition and failure rule. If one period covers all accounts and the other only the busiest account, the apparent acceleration may be a population change.
The calculator rejects a recent duration longer than the period, recent event or failure counts larger than their parent totals, and a remainder containing more failures than events. If the durations are identical, their counts must be identical too. These checks detect arithmetic contradictions; they do not verify your logs or that the windows really share a cutoff.
Keep the extraction query, cutoff, data source and policy revision with the operational record. A harmless alias belongs in this worksheet; private logs and account identifiers belong in their authorized system. If collection coverage is unknown, the calculator withholds the SLO and budget assessment rather than treating unseen failures as zero.
Decide what an alert changes before it fires
An alert is useful when somebody knows what to do with it. The SRE book’s example policy ties missed objectives to release and reliability priorities. It is explicitly an example for a particular service, not a rulebook for financial execution.
For a trading integration, an operational policy could identify the incident owner, evidence to preserve, changes to pause, fallback capability and conditions for review. Decide these matters before a metric becomes uncomfortable. The responsible team must choose which actions follow its actual risks and authority.
Keep a release freeze separate from order management. Freezing software changes does not cancel working orders. Cancelling orders does not prove every cancellation succeeded. Restoring endpoint health does not resolve an ambiguous submitted order. Refer those cases to the relevant state-reconciliation and recovery process.
Low traffic and zero denominators need explicit answers
A percentage from very few tasks can move sharply after one result. Google’s current implementation guidance warns that short lookback periods and changing traffic can produce sensitive alerts during quiet periods. The worksheet therefore shows the entered counts and avoids a universal paging threshold.
When the recent window has no eligible events, recent burn rate is undefined. It is not zero. When a positive-traffic window has zero failures and a target below 100%, its observed burn rate is zero; that describes the sample, not proof of a failure-free future.
A 100% target produces a zero error budget. The tool shows the failure count and whether any failure occurred, but withholds consumption and burn ratios that would divide by zero. It does not return infinity as a useful operating score. Unknown safety status remains unknown even when every recorded service task passed.
Do not hide one task class inside another
A combined total can make a deteriorating workload look stable when the mix changes. Suppose an invented release doubles easy status queries while payment-reconciliation failures stay unchanged. The blended completion rate can improve without repairing the consequential workflow.
Keep separate cohorts when the acceptance rules, deadlines or consequence of failure differ materially. Useful distinctions include reads versus writes, test versus live environments, and reconciliation versus order submission. Publish the scope alongside a percentage so another team can understand which experience it describes.
Likewise, a justified refusal can be the correct outcome of a policy check. Define that case in the acceptance rule; do not label every refusal a service failure or every executed action a success. A timeout with unresolved execution state needs investigation, not a convenient relabeling that restores the target.
Turn the calculation into a reviewable operational record
Use the calculator to record a declared workload, two nested windows, target, original-event counts, collection coverage and safety-review state. Download the result with its inputs and method version. The export is a reproducible calculation from those entries, not authenticated production telemetry.
A useful review asks why failures occurred, whether the measure captured the affected user experience and whether the proposed repair changes the right dependency. Compare revisions with a stable task definition. When that definition must change, publish the break in the series instead of presenting incomparable periods as an improvement.
Recalculate after the underlying evidence changes. A new export timestamp alone does not refresh the logs, retest the safety controls or close an incident. The practical outcome is a clearer engineering decision, with unresolved financial authority kept visible.
Methodology and limits
DN Error-Budget and Burn-Rate Calculator v1.0. Counts represent original eligible events, with one final success/failure classification under a predeclared deadline. Retry attempts are not added as new events. Both windows end at the same cutoff; the recent window is contained in the period. Failure counts cannot exceed event counts or contradict the outside-window remainder.
The target accepts up to four decimal places in percent. The code represents it in integer increments of one millionth of a fraction before testing the whole-event allowance. It calculates B = N(1 − s), remaining allowance B − F, consumption F/B, period burn (F/N)/(1 − s), recent burn (f/n)/(1 − s), and recent failures as a share of the period budget f/B. Percent outputs multiply ratios by 100. The maximum whole failure count is floor(B), not a rounded-up allowance.
Unknown collection coverage withholds derived budget and SLO assessments. No eligible events means no success or burn assessment; 100% targets leave division-based ratios undefined. Reported hard-stop and unknown safety states remain separate from the service arithmetic. The worksheet does not choose an alert threshold or convert failures into money, loss probability or a deployment rating.
This local calculation cannot authenticate records, find missing incidents, detect duplicate task IDs or establish that the stated windows share a cutoff. Its arithmetic checks do not replace a trace review. It performs no monitoring, alerts, order cancellation, position change or external request. Synthetic cases demonstrate the method and contain no measured agent outcomes.
The supplied sources concern service reliability. They do not establish a financial-regulatory SLO mandate or permission to tolerate an unauthorized transaction. The article’s source-review date is distinct from the date of any reader-supplied observation. Corrections should identify the affected formula or claim, method version and supporting evidence through DN’s published contact route.
Machine-readable record schema · 1.0.0
This JSON Schema documents the downloadable record, including input provenance, missing-value handling and method versions. The creation timestamp records the calculation time; it does not certify when the underlying evidence was observed.
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "urn:dn:record:dn-error-budget-burn-rate:1.0.0",
"title": "DN Error-Budget and Burn-Rate Calculator record",
"type": "object",
"additionalProperties": false,
"required": [
"schemaVersion",
"recordType",
"createdAt",
"articleSourceReviewDate",
"inputEvidenceStatus",
"inputBasis",
"exampleLabel",
"engineVersion",
"inputs",
"result"
],
"properties": {
"schemaVersion": {
"const": "1.0.0"
},
"recordType": {
"const": "dn-error-budget-burn-rate"
},
"createdAt": {
"type": "string",
"format": "date-time"
},
"articleSourceReviewDate": {
"const": "2026-11-13"
},
"inputEvidenceStatus": {
"const": "user_entered_not_independently_verified"
},
"inputBasis": {
"enum": [
"user_entered",
"illustrative_example",
"illustrative_example_modified"
]
},
"exampleLabel": {
"type": [
"string",
"null"
]
},
"engineVersion": {
"const": "1.1.0"
},
"inputs": {
"type": "object",
"additionalProperties": false,
"required": [
"scope",
"period_hours",
"recent_hours",
"target_percent",
"period_events",
"period_failed",
"recent_events",
"recent_failed",
"coverage",
"safety"
],
"properties": {
"scope": {
"type": "string",
"maxLength": 180,
"minLength": 1
},
"period_hours": {
"type": "number",
"minimum": 0.01,
"maximum": 8784
},
"recent_hours": {
"type": "number",
"minimum": 0.01,
"maximum": 8784
},
"target_percent": {
"type": "number",
"minimum": 0.0001,
"maximum": 100
},
"period_events": {
"type": "integer",
"minimum": 0,
"maximum": 1000000000
},
"period_failed": {
"type": "integer",
"minimum": 0,
"maximum": 1000000000
},
"recent_events": {
"type": "integer",
"minimum": 0,
"maximum": 1000000000
},
"recent_failed": {
"type": "integer",
"minimum": 0,
"maximum": 1000000000
},
"coverage": {
"type": "string",
"enum": [
"unknown",
"complete"
]
},
"safety": {
"type": "string",
"enum": [
"unknown",
"reported",
"none_reported"
]
}
}
},
"result": {
"type": "object",
"additionalProperties": false,
"required": [
"summary",
"metrics",
"findings"
],
"properties": {
"summary": {
"type": "string"
},
"metrics": {
"type": "array",
"items": {
"type": "object",
"additionalProperties": false,
"required": [
"label",
"value"
],
"properties": {
"label": {
"type": "string"
},
"value": {
"type": [
"number",
"string",
"null",
"boolean"
]
},
"unit": {
"type": "string"
},
"note": {
"type": "string"
}
}
}
},
"findings": {
"type": "array",
"items": {
"type": "object",
"additionalProperties": false,
"required": [
"level",
"text"
],
"properties": {
"level": {
"enum": [
"note",
"warning",
"error"
]
},
"text": {
"type": "string"
}
}
}
}
}
}
},
"allOf": [
{
"if": {
"properties": {
"inputBasis": {
"const": "user_entered"
}
}
},
"then": {
"properties": {
"exampleLabel": {
"type": "null"
}
}
},
"else": {
"properties": {
"exampleLabel": {
"type": "string",
"minLength": 1
}
}
}
}
]
}Related DN research
Frequently asked questions
Is an error budget an allowed financial loss?
No. This instrument counts eligible service events against a selected success target. It does not assign a loss allowance or authorize actions outside a mandate.
Does a five-times burn rate mean five-times trading risk?
No. It means the observed failure ratio is five times the ratio permitted by the selected SLO. Financial consequences depend on separate facts that the calculator does not model.
Should retries increase the event count?
Not for the original-task objective used here. Keep attempts linked to the original task and assess its final result against the declared deadline. A different attempt-level metric needs a separately stated denominator.
What happens at a 100% target?
The event allowance is zero. Failure counts remain visible, but budget-consumption and burn-rate ratios are undefined. No observed failures do not prove future perfection.
Can a good result override an incident or unknown safety review?
No. The tool reports hard-stop evidence separately. It does not approve recovery, resume trading or clear an unresolved review.
Sources and review dates
- Google SRE: Implementing SLOs. Service objectives, ownership, measurement boundaries and reliability decision policies; not a finance-specific mandate. Reviewed 2026-11-13.
- Google SRE: Alerting on SLOs. Burn-rate normalization and multiple observation windows; no universal trading alert threshold is imported. Reviewed 2026-11-13.
- Google SRE: Example Error Budget Policy. A labelled example linking SLO misses to release/reliability priorities; not a regulatory rule. Reviewed 2026-11-13. Source date: 2018-02-19.
- Google Cloud: Alerting on your burn rate. Eligible-event budget formulation, normalized burn and short-window/low-traffic implementation cautions. Reviewed 2026-11-13. Source date: 2026-11-11.
Turn the finding into a decision
For a bounded review of the evidence and unresolved questions behind a specific operational decision, contact the DN Research Desk. Scope, feasibility, fee and delivery terms must be agreed before work begins.
Disclosure: This is independent DN editorial research. The instrument evaluates entered assumptions and does not independently verify your evidence or approve transactions. Illustrative examples are labelled. Any affiliate placement is identified where it appears; a commercial relationship does not determine the findings. No provider endorsement or guaranteed outcome is implied.
