How this works

What we monitor

Shipzil tracks the API status of USPS, FedEx and UPS as reported by four shipping platforms: EasyPost, Shippo, ShipStation and ShipEngine. Each platform independently monitors carrier API availability for its own customers, and we aggregate those reports into one view.

Four platforms, three companies

ShipStation and ShipEngine are both Auctane products and publish the same incidents, often within minutes of each other. Counting them as two independent opinions would overstate how much corroboration there is, so for the "sources reporting a problem" figure they count once. That leaves 3 independent sources: EasyPost, Shippo, Auctane.

Why cross-reference?

No single source gives the full picture. If FedEx shows degraded on one platform and operational elsewhere, it is more likely an integration problem at that platform. If two independent companies report the same carrier as impaired, it is probably the carrier.

How uptime is calculated

For each carrier we calculate uptime separately on each platform, from the durations those platforms report between an incident opening and resolving. The headline number is the worst-performing platform, not an average.

Averaging would be misleading in two ways: it mixes integrations that are not comparable (ShipStation and ShipEngine reach USPS through Stamps.com, while EasyPost and Shippo connect directly), and it improves every carrier's number each time another platform is added. The worst platform answers a question you can act on — how bad does this get on the integration you might be using. Per-platform figures are on each carrier page.

What we exclude, and why

• Standing advisories. Incidents left unresolved for more than 48 hours are usually regional or seasonal notices, not API outages — one ran for 63 days. Counting them as continuous downtime would make every number meaningless. They are listed separately.
• Account-surface incidents. Login, dashboard, billing and API-key problems are real outages if you use a platform's interface, but a broken login page does not mean a carrier's API is failing. They appear under platform incidents instead.
• Incidents the source stopped reporting. Statuspage sometimes drops an incident from its feed without ever marking it resolved. Since we never delete records and the source never says "resolved", those would sit here as ongoing forever — one showed as an open FedEx label problem for 72 days after the platform had stopped reporting it. We now detect that and list them separately as no longer reported, ending at the last update the source published rather than a resolution time we cannot vouch for.
• Scheduled maintenance. Expected downtime, listed but not counted.
• Other carriers. DHL, Canada Post, La Poste and the rest are out of scope.

Measuring the window, not the paperwork

An incident's open and close times are not the same as the time something was broken. Platforms keep incidents open after service returns while backlogs clear — one ran seven and a half hours on paper while the affected components were actually down for three and a quarter.

So where a platform publishes component state changes alongside its updates, we measure each window from those: the moment a component left operational to the moment it came back. That is the platform's own record of what broke and for how long, which also means the severity comes from the state it set rather than from an impact field someone filled in afterwards. Carrier pages show how many of each platform's incidents were measured this way versus inferred from the incident's open and close times.

We keep every update timeline we see, because the platforms do not. Their APIs return only the most recent incidents, and the description of an incident is replaced by "resolved" once it closes — so anything we do not capture at the time is gone.

When a platform under-reports an outage

Severity is a field the platforms fill in themselves, and they do not fill it in consistently. One platform recorded a seven-hour total system failure — its own updates said "impacting all operations" and it failed over to a backup data centre — as no impact, leaving every component marked operational throughout. Taken at face value, that outage would have counted as zero downtime.

So where a platform reports no impact on something that affected carriers and reads like a failure, we raise it to minor and mark it with an asterisk. Minor rather than a guess at how bad it was: the duration already carries the weight, and inventing a severity we cannot support would be its own kind of dishonesty. Announcements — holiday deadlines, volume warnings, service changes — are left alone. 18 of 120 incidents are currently marked this way.

This matters for comparing platforms. The share of incidents a platform files as "no impact" ranges from under a tenth to a third depending on the platform, so a platform that documents its problems more candidly would otherwise look worse than one that does not.

Attributing platform-wide failures

When a platform's own API breaks, every carrier on it is affected — but the incident often tags no carrier at all, which would make those outages invisible. Where a platform tags one of its own platform-wide components, or describes a failure of a shipping surface every carrier shares (rating, labels, tracking, core API), we attribute it to all three carriers. Incidents attributed this way are labelled inferred; 14 of 120 currently are.

A note on USPS via Stamps.com

ShipStation and ShipEngine route USPS through Stamps.com, so their status reflects that integration rather than the USPS API directly. EasyPost and Shippo connect to USPS directly.

What we don't do

We do not probe carrier APIs ourselves and we have no independent response-time measurements. Everything here is what these platforms report, which means an outage nobody reported does not appear. Where platforms publish response time and error rate metrics we show them, and carrier pages mark which platforms publish nothing.

Update frequency

Status is collected every 5 minutes. Pages rebuild when something changes and at least once a day, and the dashboard refreshes status and uptime from the collector on load, so what you see is never more than one collection cycle old. Incident history is kept permanently — once recorded, an incident stays even after the source platform's own history rolls over.

Feature requests & contact

Want a carrier added? Something wrong? sam@sameerkumar.website