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
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 .-> StatsA 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 |
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.
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_idTrace attributes should include:
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-v3Do 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.
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 --> StatusHealth 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.
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.
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 --> ProgramFor 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.
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.
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 |
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.
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:
- Summary.
- Timeline.
- Detection source.
- Technical root cause.
- Affected devices, qubits, compiler versions, and time windows.
- Affected experiments and result validity.
- User impact.
- What went well.
- What failed.
- Corrective actions.
- 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 |
View diagram source
flowchart LR
Telemetry[Telemetry] --> Context[Experiment context]
Context --> Diagnosis[Diagnosis]
Diagnosis --> Action[Operational action]
Action --> Trust[Trustworthy platform]