At a glance
A real-time alert that fires when the Australia Post label-generation success rate drops below 95 percent in the last hour. Every order that cannot get a label cannot be despatched, so a label-print failure spike is a despatch-floor stoppage in the making. The card catches the spike inside the hour so the warehouse is not discovering at end-of-day that a batch of orders never printed.
| What it counts | COUNT(label_create_attempts WHERE result = success) / COUNT(label_create_attempts) over the trailing 1 hour. The alert fires when that ratio falls below 95 percent. The list shows the failing orders with the carrier error returned for each. |
| API endpoint | Australia Post Shipping and Tracking API POST /shipping/v1/labels and the underlying POST /shipping/v1/shipments create calls. A failure is any non-2xx response, a returned errors[] payload (for example invalid address, missing required field, postcode mismatch, account / charge-code error), or a request that times out before a label PDF is returned. |
| Failure taxonomy | Failures group into address-data errors (invalid or unverifiable destination, missing suburb / postcode pair), account errors (charge code disabled, credit hold, product not enabled), payload errors (weight or dimensions out of range for the product), and platform errors (API 5xx or timeout). The platform-error subset overlaps with AusPost Tracking API Unavailable / 5xx but this card is the labelling endpoint specifically. |
| Service-tier scope | All Australia Post products (Parcel Post, Express Post, international). A product-specific failure (for example an Express Post charge code not enabled on the account) shows up scoped to that product. |
| Why one hour | Label printing is bursty: warehouses batch-print in waves. A 1-hour window is short enough to catch a regression inside a single despatch wave but long enough to have a meaningful denominator. Below roughly 50 label attempts in the hour the rate is noisy. |
| Time window | RT (real time), evaluated on a rolling 1-hour basis. |
| Alert trigger | label generation success <95% in last 1h. |
| Roles | owner, operations |
Calculation
Calculated automatically from your Australia Post 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 Melbourne homewares brand batch-prints Australia Post labels in three waves a day. The 10:00 wave is its biggest. Reading taken at 10:40 AEDT on 14 Apr 26, covering the 09:40 to 10:40 window.| Failure reason | Failed attempts | Share of failures |
|---|---|---|
| Invalid / unverifiable address (suburb-postcode mismatch) | 38 | 61% |
| Charge code not enabled for Express Post | 14 | 23% |
| Weight out of range for selected product | 6 | 10% |
| API timeout (no label returned) | 4 | 6% |
| All failures | 62 | 100% |
- The address-data cluster is the real signal. 38 of 62 failures are suburb-postcode mismatches, far above the trickle you would see in a normal hour. That pattern points to an upstream change: a checkout update that stopped validating addresses, a bad import of a batch of marketplace orders, or a single large order file with malformed data. The fix is upstream of Australia Post; enabling the DPID address verification API at checkout would catch most of these before they ever reach the label call.
- The charge-code failures are an account problem, not a data problem. 14 Express Post labels failing with “charge code not enabled” means the account cannot currently bill Express Post. That blocks every Express Post order until resolved with the Australia Post account team. It is a small count but a total stoppage for that product, and those are usually your highest-value, time-sensitive orders.
- Six weight-out-of-range failures are a catalogue / packing issue. A product was selected for a parcel whose weight exceeds the product’s limit. Either the packed weight is wrong in the order, or the wrong product was chosen. Cheap to fix per order, but worth checking whether one SKU is mis-weighted at source.
- Four timeouts are the platform tail. A handful of timeouts in a busy hour is within normal noise. If timeouts dominate the failure mix instead of address errors, switch attention to AusPost Tracking API Unavailable / 5xx; the problem is the carrier endpoint, not your data, and the action is to retry with backoff rather than fix order data.
Sibling cards merchants should reference together
Label print failures is a despatch-floor stoppage alert. Pair it with these to tell a data problem from a platform problem:| Card | Why pair it with Label Print Failures Spike | What the combination tells you |
|---|---|---|
| Label Generation Success | The steady-state rate behind this alert. | This card is the spike alarm; the gauge is the trend. Use the gauge for the baseline, this card for the incident. |
| AusPost Tracking API Unavailable / 5xx | Separates platform failures from data failures. | If both fire together the problem is Australia Post’s side; if only this one fires the problem is your order data or account. |
| API Error Rate | Whole-integration error view. | Confirms whether the failures are isolated to labelling or span the integration. |
| Days to Token Expiry | A frequent silent cause. | An expired credential makes every label call fail with an auth error; check this first when the failure mix is uniform. |
| Exception Rate | Downstream of bad address data. | Address errors that slip past labelling become “address invalid” delivery exceptions later. |
Cross-connector: shopify.unfulfilled_orders | The orders stuck behind the failures. | Every failed label is an order that cannot ship; a print-failure spike pushes the unfulfilled backlog up within the hour. |
Cross-connector: bigcommerce.unfulfilled_orders | Same backlog signal on BigCommerce. | Use whichever storefront the merchant runs to size the stuck-order count. |
Reconciling against the carrier’s own dashboard
Where to look in Australia Post’s own tooling: Label-creation errors are not a tracking-portal concept, so there is no single “failures” report in MyPost Business. The authoritative sources are the API response payloads themselves and your own labelling logs. For account-level causes (charge codes, credit hold, product enablement) check Australia Post Business → MyPost Business → Account or, for eParcel, the eParcel Customer Centre account settings. The error codes returned by the labelling endpoint are documented in the Australia Post Developer Centre. The closest like-for-like check is to count, in your own shipping-platform label log, the non-2xx responses from the Australia Post labelling endpoint over the same hour. Why our number may legitimately differ from your own label log:| Reason | Direction | Why |
|---|---|---|
| Retry collapsing | Ours can be lower | If your platform retries a failed label and the retry succeeds, we count the attempt outcome; a raw log that counts every attempt including the failed first try will show more failures than our success-rate denominator implies. |
| Window boundary | Boundary minutes off | The card uses a rolling 1-hour window; a log filtered to a clock hour (10:00 to 11:00) will include and exclude different attempts at the edges. |
| Timeout classification | Either | A request that timed out client-side but actually created a label on Australia Post’s side is a failure to us (no label returned) but a success in any Australia Post account-level count. These are rare but cause a small over-count on our side. |
| Validation-only calls | Ours excludes | Address-validation or price-check calls that are not label-create attempts are excluded from this card’s denominator; a raw log that lumps all API calls together will not match. |
| Card | Expected relationship | Causes of legitimate divergence |
|---|---|---|
shopify.unfulfilled_orders | Failed labels feed the backlog. | Backlog also moves on manual fulfilment, webhook delays, and pre-orders. |
Known limitations / merchant FAQs
The alert fired but my warehouse says labels are printing fine. What is happening? Look at the failure mix. If the failures are concentrated in one product (for example Express Post) the rest of your labels print fine while that one product is blocked, usually a charge-code or product-enablement issue on the account. If the failures are concentrated in one order batch or marketplace, a bad data import is the cause and the rest of the floor is unaffected. The headline success rate is below 95 percent, but the impact is rarely uniform. How do I tell a data problem from an Australia Post outage? Read the error reasons. Address-invalid, missing-field, weight-out-of-range, and charge-code errors are data or account problems on your side and the fix is in your order data or account settings. API 5xx and timeout errors are platform problems on Australia Post’s side and the fix is to retry with backoff and wait it out. If timeouts and 5xx dominate, switch to AusPost Tracking API Unavailable / 5xx. Why a 1-hour window instead of 24 hours? Speed of detection. Label printing happens in despatch waves; a regression that starts at the 10:00 wave would be diluted to near-invisibility in a 24-hour rate but is obvious in the hour it happens. The trade-off is noise: below roughly 50 label attempts in the hour a couple of failures can trip the alert, so a very low-volume merchant should read this alongside the Label Generation Success gauge for the smoother trend. Could an expired credential cause this? Yes, and it is a common silent cause. If your Australia Post API credential or token has expired, every label call fails with an authentication error and the success rate collapses to near zero. Check Days to Token Expiry first when the failure mix is uniform auth errors; renewing the credential clears the whole spike at once. A label “failed” but the customer was still charged or a label exists. How? A client-side timeout can occur after Australia Post has already created the label and reserved the article number. The label exists on their side but no PDF came back to us, so we count it as a failure. These are rare. Reconcile against your Australia Post account article list before re-creating the label, otherwise you can end up with two labels for one order. Should I retry failed labels automatically? Only for platform errors (5xx, timeout), and with exponential backoff so you do not hammer a struggling endpoint. Never auto-retry data errors (invalid address, weight out of range): the same request will fail the same way and just inflates the failure count. Route data errors to a human or back to the order for correction. Does this card include the cost of the failed despatch? No, it counts attempts and outcomes, not cost. The business cost is indirect: every failed label is a delayed despatch, which risks an OTD miss and a WISMO ticket. Pair withshopify.unfulfilled_orders to size the stuck-order backlog the spike has created.