Quantum computing SDKs lack observability. We built QObserva to fix that.

#quantum #qiskit #braket #python

Over the past few months, we’ve been working extensively with quantum SDKs like Qiskit, Cirq, and Amazon Braket. Building circuits and running jobs is becoming more accessible, but we kept running into the same friction point—not in execution, but in understanding what actually happened after a run.

At a small scale, things feel manageable. You run a few experiments, inspect results, maybe store some outputs. But as soon as you start iterating—changing parameters, switching backends, or comparing runs over time—the workflow becomes harder to reason about. Context gets scattered across notebooks, logs, and ad-hoc scripts, and simple questions become surprisingly difficult to answer.

The problem: runs without context

As workflows grow, we repeatedly ran into questions like:

Which backend produced this result?
What changed between two runs?
Why did performance drop this week?
Are we comparing equivalent experiments across SDKs?

None of these questions are inherently complex. The issue is that the information needed to answer them isn’t captured in a structured way.

Instead, context is spread across:

Notebooks
Logs
One-off scripts
Memory (which doesn’t scale)

As a result, teams spend more time reconstructing what happened than actually improving their experiments.

This is a tooling gap, not a quantum problem

In modern software systems, this problem was solved years ago through observability. Metrics, logs, and traces provide a clear picture of system behavior, and tools like Datadog or Prometheus make debugging and optimization straightforward.

In quantum SDK workflows, that layer is still mostly missing.

You can run experiments—but tracking, comparing, and explaining them is still largely manual.

What we wanted instead

We weren’t looking for a heavy platform or something tied to a single SDK. We wanted something practical that fits into existing workflows.

The requirements were simple:

Works across Python-based quantum SDKs
Local-first (no mandatory cloud setup)
Minimal friction to adopt
Captures run-level metadata and metrics

Most importantly, it needed to make experiments comparable and explainable over time.

Introducing QObserva

QObserva is a lightweight observability layer for quantum SDK workflows.

It captures structured telemetry for each run—metadata, tags, and metrics—so you can understand what happened without piecing together context manually.

Getting started

You can set it up in a few minutes.

Install:

pip install qobserva

Start the local stack:

qobserva up

Instrument your run:

In this example we use a Qiskit StatevectorSampler to create a Bell-state run.

The same @observe_run pattern works across other SDKs too (Braket, Cirq, PennyLane, pyQuil, D-Wave) by changing the sdk tag and your SDK-specific run code.

See:

from qobserva import observe_run
from qiskit import QuantumCircuit
from qiskit.primitives import StatevectorSampler

@observe_run(
    project="first_demo",
    tags={"sdk": "qiskit", "algorithm": "bell_state"},
    benchmark_id="first_demo_bell_state",
    benchmark_params={
        "shots": 1024,
        "target_bitstrings": ["00", "11"],
    },
)
def run_algorithm():
    qc = QuantumCircuit(2, 2)
    qc.h(0)
    qc.cx(0, 1)
    qc.measure([0, 1], [0, 1])

    sampler = StatevectorSampler()
    job = sampler.run([qc], shots=1024)
    return job.result()