Bring Tracking API Unavailable / 5xx, Bring

Bring Tracking API Unavailable / 5xx for Bring stores. 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: Nerve Centre

At a glance

A real-time health alarm for the Bring Tracking API itself. Every delivery status, scan event and estimated-delivery update on your other Bring cards depends on this API returning cleanly. When Bring’s tracking endpoints start returning 5xx server errors or timing out, the whole tracking picture goes stale: parcels appear stuck even when they are moving, customer “where is my order” replies dry up, and downstream cards freeze on their last good reading. This card watches the rolling one-hour error rate against the Tracking API and fires when it crosses the floor, so you know the problem is Bring’s platform, not your data.

What it tracks	The rolling one-hour error rate of calls to the Bring Tracking API: COUNT(5xx responses + timeouts + connection failures) / COUNT(all tracking calls) over the trailing 60 minutes, plus a list of recent failing calls and their status codes.
Data source	Bring Tracking API (GET /tracking/api/v2/trackingByReference/{shipmentNumber} and related tracking endpoints). The card reads the HTTP status and response latency of each call our ingestion layer makes to refresh shipment status.
What counts as a failure	HTTP 5xx (500, 502, 503, 504), request timeouts, and connection failures. Persistent 401 / 403 authentication errors are excluded here (they are a credential problem, surfaced via Days to Token Expiry); 404 for an unknown shipment is excluded (it is a data problem, not an outage).
What goes stale when it fires	Every status-dependent card: On-Time Delivery Rate, Failed Deliveries, Exception Rate and the Mypack pickup state all freeze on their last successful read until the API recovers.
Booking vs tracking	This card watches the read side (tracking status). The write side (creating labels) is watched by Label Print Failures Spike. A Bring platform incident often hits both; an isolated tracking outage hits only this one.
Time window	RT (real time), evaluated over a rolling 1-hour window so a short Bring incident is caught quickly.
Alert trigger	API error rate >5% in last 1h. More than 1 in 20 tracking calls failing in the trailing hour.
Roles	owner, operations

Calculation

Calculated automatically from your Bring data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.

Worked example

The same Oslo outdoor-apparel brand, around 1,900 parcels a week. Vortex IQ’s ingestion layer polls the Bring Tracking API to refresh the status of in-flight consignments, making roughly 900 tracking calls an hour at peak. On a normal day the error rate sits at 0.2 to 0.4 percent (the odd transient 503, auto-retried). Reading taken at 13:00 CEST on 14 Apr 26.

In the trailing hour:

Outcome	Count (last 1h)	Share
2xx success	812	90.2%
503 Service Unavailable	61	6.8%
504 Gateway Timeout	19	2.1%
Connection timeout	8	0.9%
Total calls	900	100%
Error rate	88 / 900	9.8%

The error rate is 9.8 percent, nearly double the >5% floor, so the card is in alert. Five things to notice:

1. This is a Bring-side incident, not your problem. A burst of 503s and 504s across many different shipment numbers means the Tracking API is degraded. There is nothing to fix in your data; the action is to confirm, communicate and wait, not to start re-checking addresses.
2. Your other Bring cards are now stale, not wrong. While this fires, On-Time Delivery Rate, Exception Rate and the Mypack pickup state are showing their last successful read. Do not act on a sudden apparent freeze in those numbers during an outage; treat them as paused.
3. The customer-facing risk is silent. Customers checking tracking on your order pages or on Bring’s public tracker see no updates. Pre-empt the support spike with a banner (“Bring tracking is experiencing delays; your parcel is still on its way”) rather than letting it arrive as tickets.
4. Check the booking side too. A platform-wide Bring incident often degrades booking as well. Glance at Label Print Failures Spike: if both fire together, despatch is also blocked and you may need to hold or reroute volume.
5. Distinguish an outage from a credential problem. If the failures were 401 / 403 rather than 5xx, this card would not fire, that is an authentication issue surfaced by Days to Token Expiry. 5xx and timeouts mean the platform is up but unhealthy; 401 / 403 means your access is the problem.

Sibling cards merchants should reference together

This card tells you the tracking platform is degraded. Pair it with these to scope the blast radius:

Card	Why pair it with this alert	What the combination tells you
API Error Rate	The broad error-rate view across all Bring API calls.	This card is the tracking-specific spike; that card is the overall trend. If both rise together it is a platform-wide Bring incident.
Label Print Failures Spike	The booking (write) side of the same platform.	If both fire, despatch and tracking are both blocked; if only this fires, you can still ship but cannot see status.
Days to Token Expiry	Rules out an authentication cause.	A 5xx spike here is an outage; a 401 / 403 spike is a credential problem on that card.
Shipments with Tracking-Event Gap	The lingering effect after an outage clears.	An outage leaves a gap in the scan history; that card surfaces shipments missing events once the API recovers.
On-Time Delivery Rate	The most prominent card that goes stale during an outage.	A frozen OTD reading during an active alert here is staleness, not a real delivery problem.
Exception Rate	Another status-dependent card that pauses.	Exception counts cannot update without tracking events; read them with the outage in mind.
Cross-connector: shopify.refund_rate	Downstream sentiment effect of a tracking blackout.	A long outage drives “where is my order” tickets and refunds even if every parcel arrives on time.

Reconciling against the source

Where to look in Bring’s own tooling:

There is no merchant-facing “API uptime” dashboard inside Mybring. To confirm a Bring-side incident, the authoritative sources are the Bring developer portal status and changelog for the Tracking API, and a direct probe: try the public tracker at tracking.bring.com with a known shipment number. If the public tracker is also slow or erroring across multiple known parcels, the platform is degraded and the card’s reading is corroborated. If the public tracker works fine for the same shipments the card reports as failing, the problem may be network or rate-limiting between your integration and Bring rather than a Bring outage.

The closest like-for-like check is probe several known shipment numbers on the public tracker during the alert window and see whether they error.

Why our number may legitimately differ from a manual probe:

Reason	Direction	Why
Rate limiting	Ours higher	If our ingestion makes many calls in a burst, Bring may return 429 or 503 to throttle us while a single manual probe succeeds. A 503 from throttling looks like an outage in the error rate but is volume-driven; the card distinguishes 429 where Bring sends it.
Regional / edge routing	Either	Bring’s API may be degraded from one network path and healthy from another. Your integration and your manual browser probe can hit different edges and disagree.
Tracking-event ingestion lag	Ours appears stale	Even when the API recovers, scans queued during the outage arrive in a batch afterwards; the recovery is not instant and other cards stay stale for one or two ingestion cycles.
Window alignment	Boundary minutes	The card uses a rolling 60-minute window; a manual probe is a point-in-time check. A spike that has just ended can still keep the rolling rate above the floor for several minutes.
Carrier-local time	Display only	Any timestamps shown alongside the failing calls are converted from carrier-local time (CET / CEST) for display.

Cross-connector reconciliation:

Card	Expected relationship	Causes of legitimate divergence
shopify.refund_rate	Downstream sentiment effect of a tracking blackout.	Refund rate has many drivers; a tracking outage is a transient one.

---

Known limitations / merchant FAQs

My other Bring cards suddenly froze. Are they broken? No, they are stale. Every card that depends on tracking status (OTD, Exception Rate, Failed Deliveries, Mypack pickup state) reads from the same Tracking API. When this card is in alert, those cards are showing their last successful read and will catch up once the API recovers. Treat a freeze during an active outage as paused data, not a real change in delivery performance.

Is a 401 or 403 counted as an outage here? No. Persistent 401 / 403 is an authentication problem, not a platform outage, so it is excluded from this card and surfaced by Days to Token Expiry instead. This card counts 5xx, timeouts and connection failures, the signatures of a degraded-but-reachable platform.

Why a one-hour rolling window rather than daily uptime? To page you fast. A daily uptime figure would hide a sharp 20-minute outage. The one-hour window catches a short incident while you can still post a customer banner and decide whether to hold despatch. For the longer-term trend, read API Error Rate.

Could this fire because of rate limiting on our side rather than a Bring outage? Yes, occasionally. If our ingestion bursts and Bring throttles us, you can see 429 / 503 responses that look like an outage. The card distinguishes 429 where Bring sends it, but throttling-driven 503 can blur the line. Confirm with a manual probe of the public tracker: if it works while the card reports failures, suspect throttling or a network path, not a platform outage.

What should I tell customers during an outage? Set expectations proactively. A short banner (“Bring tracking updates are delayed; your parcel is still on its way”) on order pages and in the help centre prevents the bulk of the “where is my order” tickets. The parcels are usually moving fine; only the visibility is broken.

Can I tune the 5 percent threshold? Yes, the threshold and window are configurable per profile in the Alert Rules tab. A high-volume merchant making thousands of calls an hour may want a slightly higher floor to avoid paging on transient throttling; a low-volume merchant may want a tighter one.

What is the playbook when this card fires? In order: (1) confirm it is a Bring incident by probing the public tracker with a few known shipment numbers and checking the developer-portal status; (2) post a customer-facing banner to pre-empt the ticket spike; (3) check Label Print Failures Spike to see whether despatch is also blocked, and hold or reroute volume if it is; (4) treat all status-dependent cards as paused until the alert clears; (5) once recovered, check Shipments with Tracking-Event Gap for parcels that lost scans during the window.

---

Tracked live in Vortex IQ Nerve Centre

Bring Tracking API Unavailable / 5xx is one of hundreds of KPI pulses Vortex IQ tracks across Bring 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.