Quantum Reliability Analytics and Fleet Health

A single quantum processor can look healthy while the platform is unhealthy. Conversely, a single calibration excursion can look alarming while the fleet is behaving normally. Reliability analytics is the discipline that separates device-local variation from fleet-wide risk.

Classical reliability programs often assume that failures are discrete: a disk fails, a power supply fails, a process crashes. Quantum platforms fail more gradually. A processor drifts. A calibration becomes stale. A qubit pair becomes marginal. A compiler decision becomes inappropriate for the latest backend properties. Reliability engineering therefore needs continuous fleet health, not only incident tickets.

IBM exposes backend and calibration information to help users reason about target availability and properties, and Qiskit Experiments provides characterization and benchmarking workflows that can update backend models used for mapping and selection. These are raw ingredients; a production fleet-health program turns them into trend analysis, alerts, maintenance decisions, and admission policy. [R147]

flowchart LR
    Device[QPU telemetry] --> Normalize[Normalize]
    Normalize --> Health[Health model]
    Health --> Admission[Admission control]
    Health --> Maintenance[Maintenance planning]
    Health --> Roadmap[Roadmap evidence]
    Admission --> Jobs[Accepted workloads]

Fleet health is not one metric

No single number represents a QPU. A useful health view combines:

• availability;
• queue latency;
• calibration age;
• readout error;
• one-qubit and two-qubit error trends;
• crosstalk indicators;
• qubit-retention history;
• benchmark success rate;
• job failure rate;
• evidence-package completeness.

flowchart TB
    Health[QPU health] --> Availability[Availability]
    Health --> Fidelity[Fidelity and error]
    Health --> Drift[Drift]
    Health --> Throughput[Throughput]
    Health --> Evidence[Evidence completeness]
    Health --> UserImpact[User impact]

The operational error is to compress all of this into a single marketing score. The production move is to expose a decision-specific health model.

Reliability event taxonomy

Reliability analytics requires consistent language.

flowchart TB
    Event[Reliability event] --> Hard[Hard outage]
    Event --> Soft[Soft degradation]
    Event --> Drift[Drift event]
    Event --> Data[Data-quality event]
    Event --> Control[Control-plane event]
    Event --> User[User-impact event]

    Soft --> MarginalQubit[Marginal qubit set]
    Drift --> CalibrationStale[Stale calibration]
    Data --> MissingTelemetry[Missing telemetry]
    Control --> QueueFault[Queue or runtime failure]

A soft degradation may matter more than a hard outage. A hard outage is obvious. A degraded but still accepting QPU can silently corrupt benchmarking conclusions.

Reliability dimensions

flowchart LR
    Reliability[Reliability] --> MTTD[Mean time to detect]
    Reliability --> MTTR[Mean time to recover]
    Reliability --> Degradation[Time in degraded state]
    Reliability --> Repeatability[Repeatability of known workloads]
    Reliability --> Traceability[Traceability of evidence]

For quantum platforms, “time in degraded state” is often the most important measure. A platform can be nominally up while producing evidence that should not be trusted for a given workload class.

Health scoring model

A practical health score should be explicit and auditable.

flowchart TB
    Inputs[Inputs] --> Normalize[Normalize by target class]
    Normalize --> Rules[Policy rules]
    Rules --> Score[Health score]
    Score --> Class{Class}
    Class --> Green[Green: accept]
    Class --> Yellow[Yellow: restrict]
    Class --> Red[Red: drain]

Example health policy:

health_policy:
  target_class: superconducting_gate_model
  green:
    calibration_age_hours_max: 24
    missing_telemetry_pct_max: 1
    two_qubit_error_regression_pct_max: 10
    production_probe_success_min: 0.95
  yellow:
    allowed_workloads:
      - educational
      - simulator_validation
      - low_stakes_exploration
  red:
    actions:
      - stop_admission_for_production
      - notify_platform_owner
      - open_investigation

Do not use a fixed threshold for every workload. A toy Bell-state demonstration and a chemistry benchmark have different health requirements.

Trend, not snapshot

xychart-beta
    title "Example health trend"
    x-axis [Mon, Tue, Wed, Thu, Fri, Sat, Sun]
    y-axis "score" 0 --> 100
    line [94, 93, 90, 82, 76, 84, 91]

A snapshot says whether the system is usable now. A trend says whether a maintenance window, recalibration policy, or hardware investigation is needed.

Useful trend signals:

• monotonic decline in a qubit pair's performance;
• sudden jump after control software update;
• weekly oscillation tied to facility conditions;
• degradation correlated with queue depth;
• benchmark variance increasing while average fidelity stays stable.

Fleet-level anomaly detection

flowchart LR
    Telemetry[Telemetry stream] --> Features[Feature extraction]
    Features --> Baseline[Per-target baseline]
    Features --> Peer[Peer comparison]
    Baseline --> Detector[Anomaly detector]
    Peer --> Detector
    Detector --> Triage[Triage queue]
    Triage --> Action[Drain, recalibrate, monitor, or ignore]

Peer comparison is valuable because many platform events are not local to a qubit. A facility event, compiler release, runtime update, or telemetry pipeline failure can affect several targets at once.

Reliability warehouse

Fleet analytics should land in a warehouse, not in dashboards only.

erDiagram
    QPU ||--o{ HEALTH_SNAPSHOT : emits
    QPU ||--o{ INCIDENT : has
    QPU ||--o{ CALIBRATION_RUN : receives
    QPU ||--o{ BENCHMARK_RUN : measures
    HEALTH_SNAPSHOT ||--o{ HEALTH_COMPONENT : decomposes
    INCIDENT ||--o{ MITIGATION_ACTION : includes

Minimum tables:

Admission integration

Fleet health should affect workload routing.

sequenceDiagram
    participant User
    participant Broker
    participant Health
    participant Policy
    participant QPU
    User->>Broker: submit workload
    Broker->>Health: request target health
    Broker->>Policy: evaluate workload class
    Policy-->>Broker: allowed targets
    Broker->>QPU: submit only if target qualifies
    QPU-->>Broker: result

Without this loop, dashboards become decorative. Health must change behavior.

Reliability review

flowchart TB
    Review[Weekly reliability review] --> Incidents[Incidents]
    Review --> Trends[Trends]
    Review --> Drains[Drain decisions]
    Review --> Backlog[Reliability backlog]
    Review --> Product[User-facing commitments]

The review should answer five questions:

1. Which targets spent meaningful time in degraded state?
2. Which workloads were affected?
3. Which detections were late?
4. Which health policies were too strict or too weak?
5. Which reliability investments would reduce user-visible risk?

Operating rule

Do not ask whether the fleet is healthy. Ask healthy for which workload, under which evidence requirement, at what confidence, and with what cost of being wrong?