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

QObserva Labs — Thu, 09 Apr 2026 15:21:41 +0000

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()

Open the dashboard at:

http://localhost:3000

You’ll immediately see:

Run metadata
Tags and context
Metrics across experiments

Demo

Video: https://github.com/BuildersArk/qobserva/blob/main/docs/video/demo_qiskit_run.gif

Why this matters

Most quantum workflows today are still highly experimental. That makes clarity and iteration speed critical.

Without observability:

You lose context between runs
You repeat work unintentionally
You spend time debugging setup instead of improving algorithms

Even a small layer of structured visibility makes a noticeable difference.

What’s next

QObserva is currently in beta, and we’re shaping it based on real-world usage.

If you’re working with quantum SDKs, we’d love to understand:

What you currently track
What feels hardest to debug or compare
What would actually save you time

Try it out

Learn More:
https://qobserva.com/

Repository:
https://github.com/BuildersArk/qobserva

Feedback and issues:
https://github.com/BuildersArk/qobserva/issues

Final thought

We’re not trying to solve all of quantum computing.

The goal is simpler: make it easier to understand what your code is doing when you run it.

If that resonates, we’d love to hear your thoughts.

DEV Community: QObserva Labs