At a glance
A real-time alarm that fires when the success rate of PostNord label generation drops below 95 percent in the last hour. Every parcel needs a valid PostNord shipping label (and the embedded barcode / itemId) before it can be collected; a label that fails to generate is a parcel that physically cannot leave the building. This card watches the booking / label API for the failure rate, so a degraded PostNord endpoint, a malformed address, or a credentials problem surfaces in minutes rather than at the loading bay.
| What it tracks | The rolling 1-hour success rate of label-creation calls to PostNord: successful_labels / (successful_labels + failed_labels). The alert fires when that rate falls below 95 percent. |
| Data source | detail: alerts for Label Print Failures Spike. Reads the response status of label / booking calls against the PostNord Shipping / Booking API (label PDF or ZPL plus the returned itemId / barcode). A non-2xx response, a missing label payload, or a validation rejection counts as a failure. |
| Time window | RT (real time), evaluated on a rolling 1-hour window so a short burst of failures is caught quickly and a single bad request does not trip the alarm. |
| Alert trigger | label success <95% in last 1h. At typical despatch volume, dropping below 95 percent means roughly 1 in 20 parcels cannot be labelled, enough to stall a pack line within minutes. |
| Failure categories | Split into transport errors (PostNord endpoint 5xx / timeouts), validation errors (bad postcode, unsupported service code for the destination, weight or dimension out of range), and auth errors (expired or revoked API token). |
| Relationship to API health | A label spike driven by 5xx responses overlaps with PostNord Tracking API Unavailable / 5xx; a spike driven by validation errors is your data, not PostNord’s uptime. |
| 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 Malmo-based DTC homeware brand shipping around 90 PostNord labels an hour during the afternoon pack window. Reading taken across the 14:00 to 15:00 CET hour on 14 Mar 26.| Label attempts (1h) | Successful | Failed | Success rate | Card state |
|---|---|---|---|---|
| 92 | 91 | 1 | 98.9% | healthy |
| 88 | 79 | 9 | 89.8% | alert tripped |
| 90 | 89 | 1 | 98.9% | recovered |
<95% fires. Five things to notice:
- Nine failed labels is nine parcels stuck at the pack bench. They cannot be collected by PostNord because they have no barcode. Until the labels regenerate, those orders feed straight into Dispatch SLA Breach on N Orders Today.
- The first question is always: is this PostNord or is this us? Inspect the failure category. If the 9 failures are all 5xx / timeout, PostNord’s endpoint is degraded, confirm on PostNord Tracking API Unavailable / 5xx. If they are validation rejections, the data is the problem.
- A validation cluster usually points at one cause. Nine rejections in an hour are rarely nine different problems. The common patterns are a bad address batch from a marketing import, a service code that is not valid for the destination country (for example a domestic-only product attempted on a Norway cross-border order), or a weight that exceeds the product’s limit.
- An auth failure takes everything down at once. If the success rate collapses to near zero rather than dipping, suspect an expired token. Check Days to Token Expiry: a token that lapsed will fail 100 percent of label calls until it is refreshed.
- Recovery is the success rate climbing back above 95 percent, not the backlog clearing. Once the cause is fixed, regenerate the failed labels. The alert clears on the rolling rate, but the 9 stuck parcels still need a manual re-run before they ship, so cross-check the despatch breach count to confirm the backlog is actually moving.
Sibling cards merchants should reference together
Label print failure is a despatch-floor alarm. Pair it with these to separate cause from effect:| Card | Why pair it with Label Print Failures | What the combination tells you |
|---|---|---|
| PostNord Tracking API Unavailable / 5xx | 5xx responses cause both alarms at once. | If both fire together, the cause is PostNord uptime; if only labels fail, the cause is your data. |
| Dispatch SLA Breach on N Orders Today | Failed labels hold orders past their cut-off. | A label spike feeds the despatch-breach count within minutes. |
| Days to Token Expiry | An expired token fails 100 percent of label calls. | A near-total label collapse with a token near expiry points straight at auth. |
| API Error Rate | The broad 24-hour error view across all PostNord calls. | This card is the 1-hour label-specific spike; API Error Rate is the longer-window context. |
| On-Time Delivery Rate | The downstream outcome of parcels that ship late. | Sustained label failures degrade OTD 1 to 3 days later. |
| Shipments Over Time | Whether the spike is volume-driven. | A label failure that grows with volume can be rate limiting; on flat volume it is a discrete fault. |
Reconciling against the source
Where to look in PostNord’s own tooling: Open the PostNord Business Portal booking / label area and your PostNord developer console (the API integration that issues label calls). The closest like-for-like view is the count of labels generated in the last hour against the count of orders that attempted a label. PostNord’s portal shows successfully created shipments; the failures live only in your integration’s API logs, so the failure rate is something the portal cannot show directly, you reconcile the success side. Why our number may legitimately differ from the portal:| Reason | Direction | Why |
|---|---|---|
| Tracking-event ingestion lag | Ours can lag | A label created in the last few minutes may not yet appear in the portal’s shipment list, so a short-term count mismatch is expected. |
| Carrier-local time | Boundary off | PostNord timestamps are in carrier-local time; an hour-boundary reconciliation can shift a handful of labels into the adjacent hour. |
| Retries | Ours can count both | A label call that fails then succeeds on retry counts as one failure plus one success here, but appears in the portal only as one created shipment. The success side reconciles; the failure side does not appear in the portal at all. |
| Validation rejections never reach the portal | Ours higher | A label rejected for a bad address or invalid service code never becomes a PostNord shipment, so it is invisible in the portal but counted as a failure here. This is the point of the card. |