Forem: QObserva Labs

Configuring observability for your Qiskit runs with QObserva

QObserva Labs — Sat, 18 Apr 2026 19:36:58 +0000

If you’re working with Qiskit, you’ve probably noticed something pretty quickly:

Running circuits is straightforward.
Understanding what changed between runs… is not.

As experiments grow, context gets scattered—across notebooks, logs, and memory. That’s where QObserva fits in.

This post walks through a focused, Qiskit-only setup so you can start capturing structured telemetry from your runs with minimal changes.

Why add observability on top of Qiskit?

Qiskit already gives you counts and raw results. But when you start iterating, a few gaps show up:

It’s hard to compare runs over time
Metadata (backend, parameters, noise) isn’t consistently tracked
Context lives outside the code

QObserva adds a lightweight layer to address this:

A standard schema across runs
Derived metrics (entropy, dominance, efficiency)
Dashboards for comparing experiments
A consistent way to tag and search runs

1. Install QObserva with Qiskit support

If you’re starting with Qiskit only:

pip install qobserva
pip install qobserva-agent[qiskit]

If you plan to explore other SDKs later:

pip install qobserva-agent[all-sdks]

2. Start QObserva locally

Once installed, bring up the local stack:

qobserva up

Keep this running while executing your Qiskit scripts.

3. Instrument your Qiskit run

You don’t need to rewrite your workflow. Just wrap your existing run with @observe_run:

from qobserva import observe_run

@observe_run(
    project="qiskit_lab",
    tags={
        "sdk": "qiskit",
        "algorithm": "bell_state",
        "backend": "ibmq_qasm_simulator",
    },
)
def run_experiment():
    result = execute_quantum_circuit()
    return result

if __name__ == "__main__":
    run_experiment()

This captures run-level metadata automatically.
Explore a sample qiskit simulation here - https://github.com/BuildersArk/qobserva/blob/main/examples/qiskit_example.py

4. Tagging Qiskit runs (what actually matters)

Good observability starts with good tagging.

A simple pattern:

sdk → always "qiskit"
algorithm → "vqe", "qaoa", "bell_state"
backend → simulator or device name

Optional but useful:

noise_model
optimizer
ansatz

Start simple—expand only when needed.

5. Exploring runs in the dashboard

After running a few experiments:

Filter by project="qiskit_lab"
Compare runs by algorithm or backend
Observe how metrics evolve across iterations

This is where things become clearer:

Which changes actually mattered
How different backends behave
Where performance shifts occur

Below are few sample screen shots from the dashboard:

Execution overview

Run Details

Compare Runs

6. What this unlocks

Even with a few runs instrumented, you’ll start to see patterns:

Small parameter changes → measurable differences
Backend choices → visible tradeoffs
Experiments → easier to compare and reason about

Instead of reconstructing context, you have it captured upfront.

Explore QObserva

If you’d like to go deeper or try this out in your own workflows:

Website: https://qobserva.dev
GitHub: https://github.com/BuildersArk/qobserva

The repository includes setup instructions, examples, and the latest updates as we continue to iterate on QObserva.

What’s next

In upcoming posts, we’ll show how this pattern is applied to:

Amazon Braket
Cirq
PennyLane
pyQuil
D-Wave

The goal is to keep a single observability layer across all SDKs, so comparisons become straightforward.

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