A quantum job can finish successfully and return evidence against the user's hypothesis. It can also return an attractive estimate while losing the metadata needed to trust it. Monitoring must preserve these distinctions. Otherwise a service appears unreliable when it correctly rejects poor results, or healthy while distributing evidence that nobody can reconstruct.
Telemetry consists of observations about the system: request events, state transitions, queue times, shot counts, artifact writes, and physical diagnostics where available. A service-level indicator, or SLI, turns selected observations into a defined measure. A service-level objective, or SLO, sets a target for that measure over a stated population and window. An error budget expresses the permitted shortfall. These definitions follow the general service-engineering framework; the quantum workload determines what the indicators should count. Google's SLO guidance.
Define what the service promises
Consider an illustrative promise: “At least 99% of eligible experiments deliver a complete, validated evidence package within the agreed deadline during the accounting window.” Define eligibility before observing outcomes. The deadline may differ between interactive demonstrations and reserved hardware campaigns. Record whether cancellations, invalid submissions, and provider maintenance are included; do not remove difficult cases retroactively to improve the percentage.
The good event is delivery of valid evidence on time. Its statistical disposition may be accepted, rejected, or inconclusive. A budget-limited experiment can be inconclusive because the requested budget was insufficient, while the service has fully honored its contract. If users instead require a useful decision by a deadline, track that separate outcome measure with explicit workload and admission assumptions.
The captured Aer scenarios make the distinction concrete. Baseline completes and accepts at 5,000 shots per basis. Degraded readout completes and rejects at 200. The small-budget run completes but remains inconclusive at 1,000. The invalid-provenance scenario completes computation but fails evidence validation. These are simulator demonstrations of different states, not measurements of a production service's availability.
Work a service ledger
The following is a constructed accounting example, not a captured fleet trace. During one window, 1,000 eligible requests enter the service. Of these, 990 finish by the deadline and ten time out. Eight of the 990 completed requests lack valid evidence.
| Accounting step | Count | Interpretation |
|---|---|---|
| eligible requests | 1,000 | fixed denominator |
| completed by deadline | 990 | completion SLI: 99.0% |
| completed but invalid evidence | 8 | not good events for the stated promise |
| valid evidence delivered on time | 982 | promised-service SLI: 98.2% |
| total bad events | 18 | ten timeouts plus eight invalid packages |
A 99% objective permits ten bad events in this window. Eighteen consume 180% of that allowance, exceeding it by eight. Among the 982 good deliveries, suppose 650 accept, 280 reject, and 52 remain inconclusive. These dispositions sum to 982, but only counting the 650 acceptances would change the question from service reliability to scientific yield.
The observed bad-event fraction is 0.018. Dividing it by the allowed fraction 0.01 gives a burn ratio of 1.8 for this accounting example. That ratio describes budget consumption; it does not identify whether timeouts arose from a provider queue, a local crash, or an evidence-store failure. Error-budget policies should link the observation to a concrete investigation and release decision, rather than to an automatic claim about cause. Google's error-budget rationale.
Instrument boundaries that explain the result
Record admission, dispatch, acquisition, analysis, and evidence-publication times separately. A single end-to-end duration tells the user what happened; stage durations help an operator investigate why. Preserve job identifiers across those stages so a slow request can be followed through logs and artifacts.
Counts also need boundaries. Requested shots, acquired shots, retained shots, and analysis-eligible shots can differ after interruption or validation failure. Showing only the final accepted sample size hides wasted work and missing evidence. Record exclusions with reasons and keep them visible in cost and reliability accounting.
Physical telemetry adds context, not an automatic diagnosis. A readout statistic changing alongside a queue delay is not proof that one caused the other. A calibration identifier is useful only if it resolves to a recorded artifact with an interpretable validity scope. Hosted users may have access to less telemetry than the hardware operator; an honest service report makes that visibility limit clear.
A service error budget is distinct from an algorithm's tolerated logical failure probability and from the 0.05 statistical error allocation in Shots, Uncertainty, and Stopping Rules. They have different units, denominators, and consequences.
Exercise and worked answer
Using the constructed ledger, a dashboard reports “99% reliable” because 990 requests completed. Another reports “65% reliable” because only 650 accepted. Which matches the stated evidence-delivery SLO? If five formerly valid deliveries were discovered to have invalid evidence, with the denominator unchanged, what would the SLI and consumed budget be?
Worked answer: Neither dashboard matches the stated promise. The correct initial SLI is 982/1,000=98.2%. With five more invalid packages among the formerly good completions, good events become 977 and bad events 23. The SLI becomes 97.7%, and 23 bad events consume 230% of the ten-event allowance. Statistical rejection remains a legitimate delivered answer. The incident investigation should target the evidence failures and timeouts while retaining the disposition breakdown for scientific and product analysis.