dr.David
Rhodus
The bookREFERENCE COLLECTION Contents
Chapter 1517 / 232

Observability, Incident Response, and SREs

Operating Quantum Computers · 6 min read

Quantum operations need observability because failure is rarely obvious. A job can succeed at the API layer while producing a statistically useless result. A compiler release can reduce queue time while increasing two-qubit error exposure. A calibration can improve average fidelity while harming the qubit subset used by a critical workload.

Observability for quantum systems must connect traces, metrics, logs, artifacts, calibration, compiler state, and statistical outputs. OpenTelemetry defines a vendor-neutral observability framework for generating, collecting, and exporting telemetry such as traces, metrics, and logs [R38]. Quantum platforms need the same discipline, extended with device and experiment context.

15.1 The quantum observability problem

DIAGRAM
Diagram loads as you read
15.1 The quantum observability problem · Figure 1
View diagram source
flowchart TB
    User[User request] --> API[API trace]
    API --> Compiler[Compiler trace]
    Compiler --> Scheduler[Scheduler trace]
    Scheduler --> Runtime[Runtime trace]
    Runtime --> QPU[QPU telemetry]
    QPU --> Results[Result artifacts]
    Results --> Stats[Statistical analysis]
    Stats --> User

    Calibration[Calibration store] -. context .-> Compiler
    Calibration -. context .-> QPU
    Incidents[Incident log] -. context .-> Scheduler
    Incidents -. context .-> Stats

A normal distributed trace tells you where time went. A quantum trace must also tell you what physical assumptions were in force.

15.2 Golden signals for quantum platforms

Classical SRE often talks about latency, traffic, errors, and saturation. Quantum platforms need those plus quality signals.

Signal Quantum version
latency queue time, compile time, execution time, post-processing time
traffic jobs, circuits, shots, primitive calls, parameter evaluations
errors API failures, compilation failures, rejected jobs, execution failures
saturation queue depth, reservation utilization, control-system load
quality fidelity trends, drift, readout error, useful-result rate
uncertainty confidence interval width, estimator variance, shot efficiency
reproducibility percent of promoted results with complete provenance
DIAGRAM
Diagram loads as you read
15.2 Golden signals for quantum platforms · Figure 2
View diagram source
flowchart LR
    Metrics[Metrics] --> Latency[Latency]
    Metrics --> Traffic[Traffic]
    Metrics --> Errors[Errors]
    Metrics --> Saturation[Saturation]
    Metrics --> Quality[Quality]
    Metrics --> Uncertainty[Uncertainty]
    Metrics --> Repro[Reproducibility]

The most important metric is not raw utilization. It is useful, trustworthy, quality-adjusted output.

15.3 Trace context

Each job should carry a trace context from API submission through result interpretation.

DIAGRAM
Diagram loads as you read
15.3 Trace context · Figure 3
View diagram source
sequenceDiagram
    participant U as User client
    participant A as API
    participant C as Compiler
    participant S as Scheduler
    participant R as Runtime
    participant P as Post-processor

    U->>A: submit with trace_id
    A->>C: compile span
    C->>S: schedule span
    S->>R: execute span
    R->>P: post-process span
    P->>U: result with trace_id

Trace attributes should include:

Illustrative listing · yaml
trace_id: 93f...
project: catalyst-screening
experiment_id: exp_...
backend: provider:device
compiler_version: 2.x
calibration_snapshot: cal_...
qubit_subset: [3, 4, 7, 8]
shots: 20000
execution_mode: batch
mitigation_profile: readout-v3

Do not log secrets, proprietary source code, or raw result data into trace attributes. Use artifact references and hashes.

15.4 Health checks

A quantum health check is not a ping. The platform may be reachable while the device is operationally unsuitable for a workload.

DIAGRAM
Diagram loads as you read
15.4 Health checks · Figure 4
View diagram source
flowchart TD
    Health[Health check] --> API[API reachable]
    Health --> Queue[Queue accepting jobs]
    Health --> Compiler[Compiler target loaded]
    Health --> Cal[Calibration fresh]
    Health --> Bench[Canary circuits pass]
    Health --> Storage[Result storage writable]
    Health --> Policy[Policy engine available]
    API --> Status[Composite status]
    Queue --> Status
    Compiler --> Status
    Cal --> Status
    Bench --> Status
    Storage --> Status
    Policy --> Status

Health states should be workload-aware.

State Meaning
available platform is accepting normal workloads
degraded usable with warnings or restricted qubit subsets
calibration pending jobs may run but results require caution
admission restricted only approved workloads accepted
unavailable jobs rejected or rerouted

A status page that says “up” while calibration is stale is misleading.

15.5 Incident taxonomy

Quantum incidents can occur at multiple layers.

DIAGRAM
Diagram loads as you read
15.5 Incident taxonomy · Figure 5
View diagram source
flowchart TB
    Incident[Incident] --> Platform[Platform incident]
    Incident --> Compiler[Compiler incident]
    Incident --> Scheduler[Scheduler incident]
    Incident --> Device[Device incident]
    Incident --> Data[Data incident]
    Incident --> Scientific[Scientific validity incident]
Incident type Example
platform authentication outage, result store unavailable
compiler bad routing pass increases depth unexpectedly
scheduler priority inversion, reservation misallocation
device drift, calibration regression, readout failure
data corrupted artifact, missing provenance, wrong bit order
scientific validity published estimate invalidated by later benchmark

The last category matters. A quantum result can be operationally successful and scientifically invalid.

15.6 Incident lifecycle

NIST’s Cybersecurity Framework 2.0 organizes cybersecurity outcomes around six concurrent, continuous Functions: Govern, Identify, Protect, Detect, Respond, and Recover [R33]. They are not a six-step incident sequence. Quantum operations can use them to organize ongoing risk management, with learning and improvement feeding all six.

DIAGRAM
Diagram loads as you read
15.6 Incident lifecycle · Figure 6
View diagram source
flowchart TB
    Program[Continuous cybersecurity risk management] --> Govern[Govern]
    Program --> Identify[Identify]
    Program --> Protect[Protect]
    Program --> Detect[Detect]
    Program --> Respond[Respond]
    Program --> Recover[Recover]
    Govern --> Learn[Lessons and improvement]
    Identify --> Learn
    Protect --> Learn
    Detect --> Learn
    Respond --> Learn
    Recover --> Learn
    Learn --> Program

For quantum incidents:

Function Quantum operational meaning
Govern define ownership, severity, escalation, result invalidation policy
Identify know assets, devices, workloads, dependencies, critical experiments
Protect admission control, access control, calibration gates, backups
Detect telemetry, canaries, anomaly detection, user reports
Respond pause queues, reroute jobs, notify affected projects, preserve evidence
Recover restore service, recalibrate, reprocess results, update trust reports
Learn (local addition) update runbooks, tests, benchmarks, and policies; not a separate CSF function

15.7 Result invalidation

One of the hardest operational acts is invalidating results. If a calibration bug or compiler defect is found, the platform must identify affected runs.

DIAGRAM
Diagram loads as you read
15.7 Result invalidation · Figure 7
View diagram source
flowchart TD
    Defect[Defect discovered] --> Scope[Compute affected scope]
    Scope --> Runs[Find affected runs]
    Runs --> Severity[Classify severity]
    Severity --> Notify[Notify owners]
    Notify --> Reprocess{Can reprocess?}
    Reprocess -- yes --> ReprocessRuns[Reprocess from raw data]
    Reprocess -- no --> Rerun[Rerun experiments]
    ReprocessRuns --> Reports[Update trust reports]
    Rerun --> Reports
    Reports --> Closure[Close incident]

Affected scope may depend on:

  • compiler version,
  • backend target profile,
  • qubit subset,
  • calibration snapshot,
  • measurement mapping,
  • mitigation profile,
  • time window,
  • source language front end.

This is another reason provenance is non-negotiable.

15.8 On-call runbooks

Quantum runbooks should be concrete. A useful runbook does not say “investigate calibration.” It says which checks to run and what decisions to make.

Example: readout regression runbook.

DIAGRAM
Diagram loads as you read
15.8 On-call runbooks · Figure 8
View diagram source
flowchart TD
    Alert[Readout error alert] --> Confirm[Confirm with canary data]
    Confirm --> Localize[Localize affected qubits]
    Localize --> Active[Find active jobs using qubits]
    Active --> Pause{Pause queue?}
    Pause -- yes --> Hold[Hold affected jobs]
    Pause -- no --> Warn[Attach warning to results]
    Hold --> Recal[Run recalibration]
    Warn --> Recal
    Recal --> Verify[Verify benchmark recovery]
    Verify --> Resume[Resume or keep degraded]

Runbooks should specify:

Field Example
trigger threshold, anomaly, user report
owner platform SRE, device physicist, compiler engineer
first checks dashboards, canaries, recent releases
containment pause queue, restrict qubits, disable target
communication affected projects, status page, incident channel
recovery recalibration, rollback, re-run
closure postmortem and action items

15.9 SLOs and error budgets

Quantum SLOs need to separate service availability from result quality.

SLO Bad version Better version
availability API uptime fraction of eligible requests receiving the contracted successful outcome within its deadline
latency average queue time percentile queue time by priority class
reliability job success rate useful-result rate for accepted jobs
quality average fidelity workload-relevant quality metrics by qubit subset
reproducibility artifacts exist promoted results with complete provenance
incident response time to close time to scope affected results
DIAGRAM
Diagram loads as you read
15.9 SLOs and error budgets · Figure 9
View diagram source
flowchart LR
    SLO[SLO] --> Service[Service SLO]
    SLO --> Quality[Quality SLO]
    SLO --> Evidence[Evidence SLO]
    Service --> ErrorBudget[Operational error budget]
    Quality --> ErrorBudget
    Evidence --> ErrorBudget
    ErrorBudget --> Decisions[Release and admission decisions]

Define eligibility, exclusions, the success predicate, and the measurement window before evaluating each SLO. Capacity rejection of an otherwise eligible request counts as a failure when admission is the promised service; policy-invalid requests should be tracked separately. Do not sum unlike budgets without a declared combined success rule. A platform that meets API uptime but produces untrustworthy results is not reliable.

15.10 Postmortems

A quantum postmortem should include both platform facts and scientific impact.

DIAGRAM
Diagram loads as you read
15.10 Postmortems · Figure 10
View diagram source
flowchart TD
    Incident[Incident] --> Timeline[Timeline]
    Incident --> Technical[Technical root cause]
    Incident --> Impact[Impacted workloads]
    Incident --> Evidence[Evidence quality]
    Incident --> Actions[Corrective actions]
    Actions --> Tests[New tests]
    Actions --> Runbooks[Updated runbooks]
    Actions --> Policy[Policy changes]

Postmortem sections:

  1. Summary.
  2. Timeline.
  3. Detection source.
  4. Technical root cause.
  5. Affected devices, qubits, compiler versions, and time windows.
  6. Affected experiments and result validity.
  7. User impact.
  8. What went well.
  9. What failed.
  10. Corrective actions.
  11. Follow-up validation.

Do not close a quantum incident until affected results have been scoped.

15.11 Observability checklist

Requirement Why it matters
trace ID on every run connects API, compiler, scheduler, runtime, result
calibration context in metadata explains hardware state
quality-adjusted metrics avoids optimizing raw utilization
canary circuits detects regressions quickly
incident-linked result search enables invalidation
workload-aware health states prevents false “green” status
postmortems with scientific impact protects user trust
DIAGRAM
Diagram loads as you read
15.11 Observability checklist · Figure 11
View diagram source
flowchart LR
    Telemetry[Telemetry] --> Context[Experiment context]
    Context --> Diagnosis[Diagnosis]
    Diagnosis --> Action[Operational action]
    Action --> Trust[Trustworthy platform]

Observability is not dashboard decoration. It is the mechanism by which a quantum platform knows whether its outputs should be believed.

Additional technical sources: [R191], [R299].