IBM Quantum tutorial pitfalls for developers

Starting with IBM Quantum can feel overwhelming because hardware limits and software quirks often cause experiments to fail unexpectedly.

The direct answer is to follow a disciplined workflow: verify backend status, match circuit depth to coherence times, and apply error‑mitigation before submitting jobs.

How to check IBM Quantum backend status before running

Why real‑time calibration matters

Quantum devices drift over minutes, and their coherence times, gate errors and readout fidelities can vary significantly between calibration cycles. Running a circuit on a backend whose T1 and T2 times have degraded will inflate error rates and waste allocated shots. By consulting the latest calibration snapshot you can decide whether a circuit fits the current hardware window or whether you should postpone the job.

For example, the QuBIOS project measured a logical Bell‑pair fidelity of 97.7 % on IBM Heron r2 devices only after selecting runs that occurred during a calibration window where two‑qubit gate error rates were below 0.5 %. The same hardware, when queried later, showed gate errors near 1 % and the fidelity dropped below the physical bound. This illustrates that without checking the backend status, even a well‑designed experiment may underperform.

Accessing the IBM Quantum dashboard

Navigate to the public IBM Quantum dashboard at https://quantum-computing.ibm.com/dashboard. The “Backends” tab lists all available devices; clicking a backend opens a panel with the latest calibration table. Key rows include:

• Qubit T1 / T2 – relaxation and dephasing times in microseconds.
• Single‑qubit gate error – average error per X, H, S, etc.
• Two‑qubit gate error – error for CX or CZ gates.
• Readout error – probability of mis‑reading a |0⟩ or |1⟩ state.

These values are refreshed after each calibration cycle, typically every few hours. Note the timestamp at the top of the panel; if it is older than a few hours, consider waiting for the next update.

Programmatic check with Qiskit

In a Python script, use the IBMQ provider to pull the same data:

The properties() call returns a BackendProperties object containing the exact numbers shown on the dashboard. You can script a threshold check, for instance aborting if any two‑qubit gate error exceeds 0.006 (0.6 %).

Integrating status checks into a workflow

Before submitting a job, follow these steps:

1. Open the IBM Quantum dashboard and note the last calibration timestamp for your target backend.
2. Run a short Qiskit snippet (as above) to fetch the current BackendProperties.
3. Compare the retrieved T1/T2 and gate errors against your experiment’s tolerance (e.g., require T1 > 120 µs and CX error < 0.005).
4. If the metrics meet your criteria, proceed to submit the job; otherwise, either select a different backend or wait for the next calibration cycle.

This disciplined check reduces the likelihood of discarding results due to unexpected hardware degradation, a pitfall many developers encounter when they assume static device performance.

For a deeper look at how backend metrics were leveraged in practice, see the QuBIOS project documentation.

Matching circuit depth to qubit coherence times

Estimating the coherence window

IBM Quantum devices publish T1 and T2 values for each qubit in the backend status page. For a typical 27‑qubit device, T2 ranges from 80 µs to 150 µs. A safe rule of thumb is to keep the total execution time of a circuit below 30 % of the shortest T2 among the qubits you use. This leaves a margin for readout and transient delays.

To translate the time budget into a gate count, consult the device’s gate_time table. For example, a CX gate on IBM Heron r2 averages 200 ns, while a single‑qubit rotation is about 40 ns. If the shortest T2 is 90 µs, the maximum tolerable depth is roughly (0.3 × 90 µs) ÷ 200 ns ≈ 135 CX layers, assuming you use only CX as the dominant time‑consuming operation.

Adjusting circuit depth

When a circuit exceeds the estimated depth, consider the following reductions:

• Merge consecutive single‑qubit rotations into a single unitary using transpile with optimization_level=3.
• Replace multi‑controlled gates with ancilla‑based decompositions that use fewer CX operations.
• Exploit native gate sets; on devices where the native two‑qubit gate is iSWAP, rewrite CX sequences accordingly.

After each optimization step, re‑run transpile and check the depth attribute. If the depth remains high, prune qubits with the lowest coherence or redesign the algorithm to use fewer entangling layers.

Illustrating depth impact with QuBIOS results

The QuBIOS project (/projects/QuBIOS) ran a [[4,2,2]] error‑detected logical Bell‑pair experiment on three IBM devices (ibm_fez, ibm_marrakesh, ibm_kingston). The logical circuit required roughly 120 CX layers, which matched the devices’ coherence windows (≈ 140 µs total execution). The resulting fidelity of 97.7 % surpassed the best physical Bell pair (89.7 % fidelity at the same 10 µs window), demonstrating that staying within the coherence budget enables error‑detected protocols to outperform raw hardware.

In contrast, a 9‑qubit repetition‑code trial that exceeded the coherence limit showed a rapid fidelity drop, confirming the direct relationship between depth and decoherence. These findings reinforce the practice of estimating coherence limits before finalizing a circuit.

Tip: After transpiling, use backend.properties() to fetch the exact gate times for the selected backend, then compute the expected runtime with circuit.duration(). Adjust the circuit until the runtime stays below 30 % of the smallest T2 value.

Common Qiskit coding mistakes that waste shots

Skipping the transpile step

Many developers assume that a circuit can be sent directly to the backend. In reality, the circuit must be transpiled to match the device’s native gate set and coupling map. Without this step, the compiler inserts additional SWAPs and basis‑gate conversions, which increase the overall depth and reduce the probability of success for each shot.

# Incorrect: sending raw circuit
job = backend.run(circuit, shots=8192)

# Correct: transpile before execution
from qiskit import transpile
optimized = transpile(circuit, backend=backend, optimization_level=2)
job = backend.run(optimized, shots=8192)

Misaligned measurement registers

Qiskit requires that every qubit you intend to read out is measured into a classical bit. A common oversight is to create a ClassicalRegister with fewer bits than the number of measured qubits, or to forget to map each measurement explicitly. The result is that some qubit outcomes are discarded, wasting the allocated shots.

# Incorrect: missing classical bits for two qubits
qr = QuantumRegister(2)
cr = ClassicalRegister(1)   # only one bit!
circuit = QuantumCircuit(qr, cr)
circuit.h(qr[0])
circuit.cx(qr[0], qr[1])
circuit.measure(qr, cr)     # raises error or drops data

# Correct: matching registers
cr = ClassicalRegister(2)
circuit = QuantumCircuit(qr, cr)
circuit.measure(qr, cr)

Not resetting qubits between experiments

When reusing a circuit object for multiple parameter sweeps, developers sometimes forget to reset the qubits to the ground state. Residual excitations from a previous run can bias the measurement statistics, leading to misleading results and the need to repeat the experiment with more shots.

# Incorrect: reusing circuit without reset
circuit = QuantumCircuit(1,1)
circuit.x(0)
circuit.measure(0,0)
job1 = backend.run(circuit, shots=4096)

# later, change a parameter but keep the same circuit
circuit.rz(theta,0)   # residual X from previous run remains
job2 = backend.run(circuit, shots=4096)

# Correct: start from a fresh circuit or add reset
circuit = QuantumCircuit(1,1)
circuit.reset(0)      # ensure |0⟩ state
circuit.x(0)
circuit.measure(0,0)

Over‑specifying shots for noisy backends

Developers often request the maximum allowed shots (e.g., 100 000) assuming higher counts always improve accuracy. On noisy devices, each additional shot incurs extra queue time and may be executed after a backend calibration drift, providing no statistical benefit. A practical approach is to run a modest number of shots (2 000–5 000), evaluate the variance, and increase only if the confidence interval remains too wide.

Neglecting to enable measurement error mitigation

Qiskit includes a simple measurement error mitigation routine that can be activated with mitigate_measurement_errors=True in the execute call. Skipping this step forces the raw noisy counts to be used, which often doubles the apparent error rate and forces developers to compensate with more shots.

from qiskit import execute
result = execute(optimized, backend, shots=4096,
                 mitigate_measurement_errors=True).result()

Addressing these coding pitfalls reduces wasted shots and shortens the overall time to obtain reliable quantum results. For more guidance on backend selection, see the IBM Quantum status page. If you need a sandbox environment for testing Qiskit scripts, explore Qubitpage’s QuBIOS simulations.

Step‑by‑step workflow to submit a reliable job

1. Import the required Qiskit modules and load your IBM Quantum account token using IBMQ.save_account and IBMQ.load_account. This registers your credentials for the session.

2. Query the provider for the list of available backends with IBMQ.get_provider().backends(). Filter the list by backend.status().operational and backend.configuration().n_qubits to keep only functional devices that meet your qubit count.

3. Select a backend that matches your circuit depth and coherence budget, for example backend = provider.get_backend('ibmq_montreal'). Verify the average T1/T2 times with backend.properties().t1 and backend.properties().t2 to ensure the device can sustain the intended runtime.

4. Transpile your circuit for the chosen backend using transpile(circuit, backend=backend, optimization_level=2). The transpiler will map logical qubits to physical ones and respect the device’s coupling map, reducing unnecessary SWAP operations.

5. Submit the job with backend.run(transpiled_circuit, shots=8192). Store the returned Job object so you can monitor progress and retrieve results later.

6. Poll the job status with job.status() until it reaches JobStatus.DONE. If the job fails, inspect job.error_message() and consider adjusting circuit depth or increasing the number of shots.

7. When the job completes, fetch the raw counts using result = job.result() and counts = result.get_counts(). Apply a simple readout error mitigation step, such as the measurement calibration matrix provided by CompleteMeasFitter, to improve fidelity.

8. Validate the output by comparing the mitigated distribution against the expected theoretical probabilities. Plot the results with plot_histogram and, if needed, repeat the experiment with a different backend to confirm consistency.

Tip: Always run a short “test” circuit (e.g., a single‑qubit X gate) on the selected backend before launching the full job; this quickly confirms that the device is reachable and that your authentication token is still valid.

For deeper insights into quantum‑hardware behavior, see the QuBIOS research page where error‑detected logical Bell pairs and repetition codes are analysed on IBM devices. If you need assistance with account setup or job troubleshooting, contact us through the support page.

Error‑mitigation techniques you should enable

Readout error mitigation

IBM Quantum devices report measurement outcomes that are biased by detector imperfections. The standard approach is to build a calibration matrix by preparing each computational basis state on the target qubits and measuring the resulting distribution. The inverse of this matrix is then applied to raw counts, effectively correcting systematic readout flips. In practice, you run a qiskit.ignis.mitigation.readout_meas_mitigation.CalibrationFitter routine before the main experiment, store the calibration matrix, and use apply on the result object. This step adds only a few seconds of extra runtime but can raise fidelity by 5–10 % on devices with typical readout error rates of 2–4 %.

Zero‑noise extrapolation (ZNE)

ZNE works by artificially stretching the circuit depth, usually by inserting identity pairs or gate repetitions, and then fitting the observable values to a zero‑noise limit. In Qiskit you can use qiskit.utils.ZNE with a linear or exponential extrapolation model. The key is to keep the stretched circuits short enough that the device does not exceed its coherence window; otherwise the extrapolation becomes unreliable. On a 9‑qubit repetition code, applying ZNE reduced the logical error rate from roughly 3 % to about 1.8 % when the stretch factor was limited to 1.5×, demonstrating that modest extrapolation already yields measurable gains.

Measurement error calibration for encoded runs

When running error‑correcting codes such as the 9‑qubit repetition code reported in the QuBIOS project, the raw syndrome measurements inherit both readout bias and gate‑induced errors. A combined calibration routine first performs the readout matrix for the physical qubits, then runs the encoded circuit with a known logical state (e.g., all‑zero) to capture how the code maps errors to measured syndromes. By applying the inverse readout matrix followed by a decoder‑specific correction table, the logical qubit can be kept coherent for ~150 µs, a dramatic improvement over the 41–75 µs bare‑qubit lifetime.

Practical checklist

• Run a full readout calibration on the exact qubit subset you will use.
• Generate stretched circuits for ZNE with a maximum stretch factor of 1.5–2 to stay within T1/T2 limits.
• Include a reference run of the encoded circuit (e.g., logical |0⟩) to build a measurement‑error correction table for the code.
• Apply the correction steps in the order: readout matrix → ZNE extrapolation → code‑specific syndrome correction.

By integrating these three techniques, developers can routinely achieve logical error rates that approach the 3 % benchmark reported for the 9‑qubit repetition code, and often surpass it on newer backends. For further guidance on combining mitigation with job submission, see the earlier workflow section or contact the Qubitpage team via /contact.

Feature comparison of IBM Quantum backends

When selecting an IBM Quantum device for a new experiment, the most decisive factors are the number of physical qubits, the coherence times (T1 and T2) and the maximum circuit depth that the system can sustain before decoherence dominates. The three devices most often used in recent research – ibm_fez, ibm_marrakesh and ibm_kingston – differ noticeably in these metrics, and the choice can change the outcome of a benchmark such as the logical Bell‑pair experiment reported in the QuBIOS project.

Below is a concise comparison that highlights the practical limits you will encounter when translating a Qiskit circuit into a job for each backend. The values are averages taken from the IBM system status page on 7 Nov 2026, the same day the QuBIOS team ran ~40 jobs on the three machines.

All three systems expose the same 27‑qubit topology, but the slight variations in T1 and T2 translate into different depth budgets. For example, a circuit that reaches depth 115 will run comfortably on ibm_fez but will be close to the limit on ibm_kingston. When the depth exceeds the reported maximum, the backend automatically truncates the circuit, which can lead to unexpected fidelity loss.

Another practical consideration is the calibration cycle. Each device updates its qubit parameters roughly every 12 hours; submitting a job immediately after a calibration refresh often yields higher fidelity because the T1/T2 values are at their peak. Conversely, jobs submitted toward the end of a cycle may suffer from drift, especially on ibm_marrakesh, where the average T2 shows a wider spread.

For developers who need to run error‑mitigation routines, the depth ceiling matters because additional measurement‑error correction circuits increase depth. On ibm_fez you can typically add a 20‑gate mitigation layer without exceeding the 120‑gate limit, while on ibm_kingston you should keep the mitigation overhead under 10 gates.

Finally, the choice of backend influences queue times. Historically, ibm_fez has a slightly higher demand, resulting in average wait times of 30 minutes, whereas ibm_kingston often clears within 10 minutes. Balancing depth capacity against queue latency is a key part of the workflow described in section 4 of this tutorial series.

Frequently asked questions

What is the best way to monitor qubit error rates on IBM Quantum?

Use the calibration dashboard provided in the IBM Quantum Console, which lists T1, T2, readout error, and two‑qubit gate error for each qubit. Export the JSON file daily and compare the values with a simple script that flags any metric deviating more than 10 % from the previous week. This approach lets you spot deteriorating qubits before they affect your jobs.

How many shots should I use for a small circuit to get reliable statistics?

For circuits with fewer than ten measurement outcomes, start with 1 000 shots and evaluate the standard error of the probability estimates. If the error exceeds 1 % of the observed probability, double the shot count until the margin falls below that threshold. In practice, 2 000–4 000 shots often balance runtime and statistical confidence for small benchmarks.

Can I run the same circuit on multiple backends simultaneously?

IBM Quantum does not provide a built‑in “broadcast” feature, but you can script parallel submissions using the Qiskit IBMQJobManager class. Create a list of target backends, submit the circuit to each, and collect the JobResult objects once all jobs finish. This manual parallelism lets you compare performance across devices in a single experiment.

What does ‘backend calibration data’ include and why does it matter?

Calibration data comprises qubit relaxation times (T1), dephasing times (T2), single‑ and two‑qubit gate error rates, and readout error percentages. These numbers define the error model that Qiskit uses for noise simulations and influence the selection of qubits for a given circuit. Ignoring recent calibration can lead to optimistic fidelity estimates that do not match actual hardware runs.

How do I know if my circuit is too deep for the selected device?

Check the device’s reported coherence times and compare them with the total gate duration of your circuit, which you can obtain from transpile(..., optimization_level=3) and the duration attribute of the resulting QuantumCircuit. If the circuit duration exceeds roughly 70 % of the shortest T1 among the allocated qubits, the likelihood of decoherence errors rises sharply. Reducing depth by merging gates or using native two‑qubit gates often brings the circuit back within the safe window.

Wrapping up the IBM Quantum pitfalls guide

When you start a new IBM Quantum project, begin by checking the device calibration data and selecting a backend whose error rates match the tolerance of your algorithm. Use the ibm_fez or ibm_marrakesh devices for small circuits, but switch to a larger QPU only after confirming that your gate depth stays well below the reported coherence times.

Structure your code with QLang or the standard Qiskit primitives, and always validate the transpiled circuit before submission. Insert explicit measurement resets and avoid implicit assumptions about qubit ordering; a mismatched layout can inflate error dramatically. After each run, compare the observed fidelity against the device’s baseline (for example, the 97.7 % logical Bell‑pair result on IBM Kingston) to detect regressions early.

Finally, keep a small test suite that runs on a simulator and on real hardware side‑by‑side; this habit catches differences caused by noise models or backend updates. By following these steps you reduce wasted queue time and improve the reliability of your results.

Ready to explore more practical tools? Visit the most relevant Qubitpage page for additional guidance.