Failed Orders (24h), OpenCart

Count of OpenCart orders that landed in a Failed status in the last 24 hours. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to act on it.

Metrics type: Key Metrics • Category: Ecommerce Platform

The number of orders that hit a Failed status in the last 24 hours, the fastest signal that a payment gateway, extension, or checkout step is dropping live sales.

At a glance

When a customer reaches OpenCart’s checkout but the order does not complete, OpenCart records it with a failed or unfinished order status rather than a confirmed one. This card counts those in a rolling 24-hour window. A handful is normal background noise (mistyped cards, abandoned final steps). A sudden cluster means something broke: a gateway declined batch, an SSL or API credential expired, or an extension conflict knocked out the place-order step. The trigger is >5 in 24 hours.

What it counts	COUNT(orders) whose current order_status_id maps to a Failed or unfinished state, where the order was created in the last 24 hours.
What “Failed” means in OpenCart	OpenCart writes an order row as soon as checkout begins and assigns a status as the customer progresses. An order that never reaches a confirmed status (gateway decline, processing error, customer drop at the final step) sits in a failed or missing-orders state (often order_status_id = 0 or a configured Failed status).
Configurable statuses	OpenCart order statuses are merchant-editable. Most stores keep a status named Failed; some rename or add their own. The connector maps the store’s failed-equivalent status, not just a fixed label.
vs cancelled	A cancelled order was confirmed then voided by the merchant or customer. A failed order never confirmed. They are different statuses and different cards; see Cancellation Rate.
vs missing orders	OpenCart’s “Missing Orders” filter shows order_status_id = 0 rows, started checkouts that never confirmed. Many failed orders live here.
Currency	n/a, this is a count, not a value. For the money at stake see Revenue at Risk (live).
Multi-store	Counts across all store_id values on the instance by default; the detail view splits by store.
Time window	24H (rolling 24 hours)
Alert trigger	>5, driven by sentiment on order health
Roles	owner, operations

Calculation

COUNT(orders)
  WHERE order_status = 'failed'
    AND date_added >= NOW() - 24h

Worked example

A Spanish supplements merchant on OpenCart 3.0 normally sees one or two failed orders a day, well below the >5 trigger. On 14 May 26 their card reads 23 failed orders in 24 hours.

Hour block (14 May 26)	Orders attempted	Confirmed	Failed
00:00 to 08:00	41	39	2
08:00 to 12:00	58	41	17
12:00 to 16:00	36	32	4
16:00 to 24:00	47	47	0
Failed Orders (24h) (this card)			23

What’s interesting here:

1. The failures cluster in one window. Seventeen of the 23 failures landed between 08:00 and 12:00. A clustered failure is almost always a single root cause, not 23 unlucky customers. The shape points straight at a window, not a trend.
2. The cause was an expired payment API credential. The store’s primary card gateway rotated its API key overnight and the merchant had not updated the module. Every card payment in the morning window declined at the gateway and OpenCart logged each as failed. After 12:00 a developer pasted the new key and confirmations resumed.
3. The card fired the alert at roughly 09:30, once the morning cluster crossed >5. That is hours before the merchant would have noticed from a quiet sales total, and before the lunchtime peak made it worse. Speed is the whole point of a 24-hour window on a Key Metrics card.
4. The money at stake is on a sibling card. Twenty-three failed orders at a roughly 35 euro average order value is around 800 euros of attempted sales that did not collect. Revenue at Risk (live) puts the currency figure next to the count.
5. The fix loop is short. Confirm the cluster, check the error log for gateway decline messages, verify the gateway credential and SSL, then watch the count fall. Once new orders confirm again the rolling 24-hour figure decays as the bad window ages out.

Sibling cards merchants should reference together

Card	Why pair it with Failed Orders (24h)
Revenue at Risk (live)	Puts a currency value on the failed orders. The count tells you how many; this tells you how much.
Order Volume	The healthy counterpart. A failed spike with flat confirmed volume means you are losing the top of the funnel.
Pending Orders	Orders stuck before confirmation. A gateway issue can inflate pending and failed together.
Order Status Distribution	Shows where the failures sit in the full status mix.
Platform Error Spike or Extension Conflict	A checkout-template conflict can cause failures directly. Watch both after any update.
Error Log Volume (24h)	Gateway declines and PHP errors land in the log. A correlated spike confirms the root cause.

Reconciling against OpenCart

Where to look in OpenCart admin:

Sales → Orders, then filter by Order Status to your Failed status and set the date range to the last day. OpenCart also has a Missing Orders filter (orders with order_status_id = 0, started but never confirmed) which captures many failed checkouts. Reports → Sales → Orders can be grouped by status for a periodic view. The underlying rows live in oc_order with the status in order_status_id and the history in oc_order_history.

Other OpenCart views that look like the same number but are not:

• Sales → Orders default view: hides order_status_id = 0 (missing) orders unless you explicitly filter for them, so the default list understates failures.
• Reports → Sales: aggregates confirmed sales and usually excludes failed and missing orders entirely.
• Dashboard order count tile: typically counts confirmed orders only.

Why our number may legitimately differ:

Reason	Direction of divergence
Time zone. OpenCart admin runs on the store timezone; Vortex IQ evaluates the 24-hour window in UTC by default. Failures near the boundary fall on different sides.	Boundary effects on the latest hour
Status mapping. OpenCart statuses are merchant-configurable. If a store renames or splits Failed into custom statuses, our mapping follows the configured failed-equivalent, which may differ from a literal label filter in the admin.	Either direction depending on config
Missing vs failed. Some stores treat order_status_id = 0 (missing) as failed and some do not. We follow the store’s configuration, which can differ from an ad-hoc admin filter.	Either direction
Multi-store. A store_id-filtered admin view shows one store; this card sums all stores by default.	Vortex IQ higher than a single-store admin view
Sync lag. Failures in the last few minutes appear on the next sync.	Self-resolves at next sync

Cross-connector note: when a payment processor connector is linked (for example Stripe or PayPal), a failed-order spike on this card should correlate with a decline-rate rise on the processor. If OpenCart shows failures but the processor shows clean authorisations, the break is between checkout and the gateway (an extension or credential issue), not at the gateway itself.

Known limitations / merchant FAQs

What counts as a failed order in OpenCart? An order that started checkout but never reached a confirmed status: gateway declines, processing errors, and customers who dropped at the final place-order step. OpenCart writes the order row early and assigns a failed or missing status when it does not complete. This card counts those created in the last 24 hours.

Is a small number of failed orders normal? Yes. One or two a day from mistyped cards and last-step abandonment is background noise. That is why the trigger is >5 in 24 hours, not >0. The signal is a cluster, not the occasional failure.

What is the difference between failed and cancelled? Failed orders never confirmed. Cancelled orders confirmed and were then voided by the merchant or customer. They are separate statuses and separate cards. For cancellations see Cancellation Rate.

My count spiked, where do I start? Look at the timing first. A clustered spike points to a single cause: an expired gateway credential, an SSL or API failure, or an extension conflict on the checkout. Check the error log for decline messages and the conflicts card for a recent collision.

Why does the admin show fewer failed orders than this card? The default Sales → Orders list hides missing orders (order_status_id = 0). Many failed checkouts live there. Filter explicitly for the Failed status and Missing Orders to see the full set, and remember this card may sum multiple stores.

Can an extension conflict cause failed orders? Yes, directly. A conflict on a checkout or payment template can break the place-order step or hide a payment button, so customers cannot complete. Watch this card alongside Extension / Modification Conflicts after any core update.

How much money is this costing me? This card is a count. For the currency value of the failed orders, see Revenue at Risk (live), which multiplies the failed and unconfirmed orders by their order totals.

Why does the number fall on its own after I fix the cause? Because it is a rolling 24-hour window. Once new orders confirm again, the failed window from earlier ages out hour by hour and the count decays back to baseline without any further action.

---

Tracked live in Vortex IQ Nerve Centre

Failed Orders (24h) is one of hundreds of KPI pulses Vortex IQ tracks across OpenCart and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English.

Start for free or book a demo to see this metric running on your own data.