Skip to main content
Metrics type: Key Metrics • Category: Nerve Centre

​
At a glance

A real-time alarm on the health of PostNord’s API surface. It fires when the error rate (5xx server errors and timeouts) on calls to PostNord’s tracking and shipment endpoints exceeds 5 percent over the last hour. When PostNord’s API is unhealthy two things break at once: new tracking events stop ingesting (so every delivery metric goes stale), and label / booking calls may fail (so parcels cannot be despatched). This card is the single pane that tells you “the carrier’s platform is the problem, not your data”.

​
Calculation

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

​
Worked example

A Helsinki-based DTC electronics brand polling PostNord tracking events for around 4,000 in-flight parcels, roughly 1,200 API calls an hour. Reading taken across the 10:00 to 11:00 EET hour on 14 Mar 26. In the middle row the error rate hits 8.0 percent and the alert at >5% fires. Five things to notice:
  1. The immediate consequence is stale data, not lost data. Events that PostNord could not serve during the outage are not gone: they backfill once the API recovers. But while the alarm is active, every delivery card is frozen at its last successful read. Do not act on a sudden “OTD drop” during an API outage, it is an ingestion artefact.
  2. Check whether labels are also failing. If Label Print Failures Spike fires at the same time, the outage is hitting the booking endpoints too and parcels cannot be despatched. That escalates the incident from “metrics stale” to “operations blocked”.
  3. Confirm it is PostNord, not you. A genuine 5xx surge is PostNord-side. If the errors are 4xx instead (and so not counted here), suspect an expired token or a request change on your side, look at API Error Rate and Days to Token Expiry.
  4. Tracking-event gaps will appear during the window. Parcels stop receiving scans because the events cannot ingest. Shipments with Tracking-Event Gap will climb. Expect it to self-clear as the backlog ingests after recovery.
  5. Recovery means the rate falls back under 5 percent and the backlog drains. The alert clears on the rolling rate, but give ingestion 30 minutes to a few hours to backfill the missed scans before trusting the delivery cards again. PostNord scan timestamps are in carrier-local time, so backfilled events land on their original scan day, not the ingest day.

​
Sibling cards merchants should reference together

API availability is the foundation every PostNord card stands on. Pair it with these:

​
Reconciling against the source

Where to look in PostNord’s own tooling: Check the PostNord Developer Portal for API status and any published incident notices, and the PostNord Business Portal to confirm whether tracking lookups are responding there too. The closest like-for-like check is to run a manual tracking lookup in the portal during the alert: if the portal is also slow or erroring, the outage is genuinely PostNord-side; if the portal works but your integration errors, the problem is between your integration and PostNord (network, region, or a request change). Why our number may legitimately differ from PostNord’s status page:

​
Known limitations / merchant FAQs

My OTD dropped sharply at the same moment this alert fired. Is delivery actually getting worse? Almost certainly not. During an API outage, delivery scans cannot ingest, so the delivery cards freeze and can read as if performance dropped. The “drop” is an ingestion artefact. Wait for the alert to clear and the backfill to complete, then re-read OTD. The real figure appears once the missed scans land. The alert fires but my labels still print fine. Why? PostNord exposes multiple endpoints. A degradation can hit the tracking-events endpoint while leaving the booking / label endpoint healthy, or vice versa. If labels are fine, despatch is not blocked; the impact is limited to stale tracking data. Watch Label Print Failures Spike to confirm the booking side stays healthy. How do I tell a PostNord outage from a token problem on my side? Error class. This card counts only 5xx and timeouts, which are server-side. A token or request problem produces 4xx errors, which show on API Error Rate, not here. If this card is quiet but API Error Rate is high, check Days to Token Expiry first. Do I lose tracking events permanently during an outage? No. PostNord retains the scan history; once the API recovers, ingestion backfills the missed events. They land with their original carrier-local scan timestamps, so the delivery-day attribution stays correct. Allow 30 minutes to a few hours for the backlog to drain before trusting the delivery cards. A regional outage only affected my Norway parcels. Why was the overall rate only mildly elevated? Because the error rate is blended across all your PostNord traffic. If Norway is 15 percent of your volume and the Norway endpoint is fully down, your overall rate rises by roughly that share. For a country-specific outage, cross-check OTD by Nordic Country and the tracking-gap card to see the concentration. What is the playbook when the alert fires? In order: (1) confirm it is PostNord by running a manual lookup in the PostNord Developer Portal / Business Portal, (2) check whether labels are failing too, (3) if despatch is blocked, switch time-sensitive volume to a fallback carrier (Bring / DPD) for the duration, (4) treat all delivery cards as stale until ingestion backfills, (5) once recovered, verify Shipments with Tracking-Event Gap has self-cleared.

​
Tracked live in Vortex IQ Nerve Centre

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