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”.
| What it tracks | The rolling 1-hour error rate across calls to the PostNord API: (5xx_responses + timeouts) / total_requests. The alert fires above 5 percent. |
| Data source | detail: alerts for PostNord Tracking API Unavailable / 5xx. Reads the HTTP status of every call Vortex IQ makes to PostNord’s tracking and shipment endpoints (GET /shipments/v1/parcels, GET /shipments/v1/parcels/{id}/events, GET /shipments/v1/manifests, and the label / booking endpoints). 5xx and timeouts count as errors; 4xx auth / validation failures are tracked separately. |
| Time window | RT (real time), evaluated on a rolling 1-hour window. |
| Alert trigger | API error rate >5% in last 1h. Above this, tracking-event ingestion lags and the freshness of every delivery card degrades. |
| What it does NOT cover | 4xx client errors (bad token, malformed request, invalid service code) are not 5xx and are surfaced on API Error Rate and Label Print Failures Spike. This card is specifically about PostNord-side availability. |
| Downstream effect | While the alert is active, treat OTD, transit, exception, and tracking-gap readings as stale: they are only as fresh as the last successful ingest. |
| Roles | owner, operations |
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.| API calls (1h) | 5xx + timeouts | Error rate | Card state |
|---|---|---|---|
| 1,210 | 9 | 0.7% | healthy |
| 1,180 | 94 | 8.0% | alert tripped |
| 1,205 | 6 | 0.5% | recovered |
>5% fires. Five things to notice:
- 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.
- 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”.
- 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.
- 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.
- 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:| Card | Why pair it with API Unavailable / 5xx | What the combination tells you |
|---|---|---|
| Label Print Failures Spike | An outage that hits booking endpoints stops despatch. | Both firing together escalates from “stale metrics” to “blocked operations”. |
| API Error Rate | The broader 24-hour error view including 4xx. | Distinguishes a PostNord 5xx outage from a 4xx auth / request problem on your side. |
| Days to Token Expiry | Rules out auth as the cause. | If errors are 4xx and the token is near expiry, it is auth, not a PostNord outage. |
| Shipments with Tracking-Event Gap | The visible symptom of stalled ingestion. | Gaps climb during the outage and self-clear on backfill. |
| Dispatch SLA Breach on N Orders Today | An outage at cut-off causes a breach. | If the outage hits during the despatch window, the breach count spikes. |
| On-Time Delivery Rate | The metric most distorted by stale data. | Treat OTD as frozen during the outage; do not action a “drop” until ingestion recovers. |
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:| Reason | Direction | Why |
|---|---|---|
| Tracking-event ingestion lag | Ours can lag | A status page may show “all green” while a specific endpoint or region degrades; the card reflects the actual errors your calls received. |
| Carrier-local time | Boundary off | PostNord status timelines and scan timestamps use carrier-local time; an hour-boundary on your error window can shift a few calls. |
| Partial / regional outage | Either | PostNord operates per-country networks; a Denmark-only endpoint degradation raises your error rate only in proportion to your Danish traffic, so your rate can differ from a global status indicator. |
| Retries | Ours can smooth | A call that 5xx-errors then succeeds on retry counts as both an error and a success here; aggressive retries can mask the underlying instability in the raw rate. |