Carrier Integration Software Uptime: 12 SLAs Compared

Why "99.99% uptime" on a homepage is not an SLA

Three numbers get thrown around in carrier integration software marketing, and vendors rarely tell you which one you're looking at. A contractual SLA has a measurement window, a defined method, and a service credit if the vendor misses it. A marketing uptime claim is a number on a homepage with no penalty attached if it's wrong. And independently measured uptime is whatever a third-party monitor recorded, whether or not the vendor agrees with it. Confuse these three and your carrier integration software uptime assumptions in your own SLO math will be wrong from day one.

Here's what a real SLA document looks like. nShift's Ship and Track SLA specifies that planned maintenance is excluded in calculating Service uptime, and ties response-time and API rate-limit commitments to specific subscription tiers rather than a single blanket number. That's the level of specificity you should be demanding. Most vendors in this category don't provide it, and it's worth knowing exactly which ones do before you build a dependency on their number.

The benchmark table

Below is what's actually published, as of 22 September 2026. Where no source document or measurement exists, the cell says "Not published" rather than an estimate.

A few of these deserve unpacking. EasyPost's own product page states EasyPost is engineered for high-volume shipping, with 99.99% historic uptime maintained through consecutive peak seasons, and repeats this framing across its comparison pages against ProShip and Easyship, describing itself as the platform with EasyPost publishes a 99.99% uptime SLA maintained through consecutive peak seasons. Read that carefully: it's called an "SLA" in the copy, but no separate contractual document with a measurement window or service credit schedule was found. One workflow review noted that the 99.99% uptime figure is from our experience over eight months, while EasyPost's official SLA for enterprise customers guarantees 99.9% uptime, suggesting the two numbers coexist and get blended depending on which page you land on. Shippo, by contrast, publishes nothing comparable. A direct comparison notes that EasyPost advertises a 99.99% uptime SLA, which is a self-reported vendor claim rather than an audited number; Shippo publishes no comparable SLA, so weigh that gap as a claim to verify, not a guarantee.

Sendcloud's number sits in the same bucket as EasyPost's. nShift's own competitive comparison states plainly that 99.99% uptime is a Sendcloud homepage marketing claim; a public status page is available; no public contractual SLA document identified as of July 2026. That's a competitor's assessment, so treat it with the usual scepticism reserved for vendor-versus-vendor pages, but the underlying claim (round number, no linked contract) matches what a search of Sendcloud's own site returns.

Cargoson's figure comes from a different source entirely: not the vendor's own product page, but a reply to a customer review. The company wrote that Cargoson is committed to 24/7 availability and boasts over 99.9% uptime record over six years—reflecting our dedication to providing a reliable and uninterrupted experience. That's a real statement, but it's a review response, not a contract, and a separate vendor-assessment site scoring Cargoson against buyer-risk criteria rates it 3.9 out of 5 on Uptime, noting the platform is cloud-hosted SaaS with carrier-provided tracking uptime inherited in platform and standard SLA customer support included on mid-tier plans and above. Same treatment applies here as to EasyPost and Sendcloud: a claim, not a contract.

What independent monitoring actually shows

One dataset in this research is genuinely third-party and dated. StatusBird ran continuous synthetic checks and reported that the numbers below come from our own independent status checks, run every 2 minutes against each service, covering the 90 days ending July 2026. The headline finding: FedEx, USPS, DHL eCommerce, EasyPost, ShipBob, Deliverr, Flexport, and UPS all posted 100% uptime with zero major incidents over the past 90 days, while AfterShip finished last at 97.11% after two outages that together cost nearly 59 hours of downtime. StatusBird itself called this the widest reliability spread of any category StatusBird monitors. The pattern worth noting: the underlying carriers (FedEx, USPS, DHL eCommerce, UPS) were flawless in that window. The downtime concentrated in the middleware and post-purchase layer, not the carrier networks themselves. FedEx's own tracking API backs this up on a separate, live monitor: as of the latest check it showed a 30-day uptime is 100.00%, with 0 incidents recorded this month. Average response latency across all regions is 315ms.

Treat both of these datasets with the limits they carry. StatusBird's checks run every 2 minutes against each service from its own monitoring infrastructure, not from inside your production traffic path. The FedEx figure comes from a monitor that monitors the FedEx API from 4 global regions (US West, US East, Europe, Asia Pacific) every 300 minutes, which is a coarser sampling interval than StatusBird's. Neither dataset catches partial degradations, elevated error rates that don't cross a full "down" threshold, or region-specific slowdowns that hit only your traffic corridor. Sandbox uptime, which is where a lot of integration testing actually happens, isn't covered by any source here.

What "Not published" costs you as an architect

If a vendor in your dependency graph has no published SLA, your own error-budget arithmetic has nothing to inherit from. You can't subtract a carrier middleware's contractual downtime allowance from your own SLO target if that allowance doesn't exist on paper. The honest move is to treat that dependency as unbounded risk and size your retry budget, circuit-breaker thresholds, and dead-letter queue capacity as if the upstream could fail without warning or recourse. When you're evaluating a vendor for a new integration, four questions separate a real SLA from a homepage number:

• What exactly counts as "successful"? A request that returns 200 but with stale or wrong data isn't the same as true availability, and the definition matters more than the percentage.
• What's excluded? nShift's document explicitly excludes planned maintenance from the uptime calculation, which is standard practice but needs to be stated, not assumed.
• What's the remedy? A service credit against your invoice is not compensation for the orders you lost during the outage. Know the ceiling before you sign.
• Is the number audited or self-reported? A percentage in a review reply, however sincere, is not the same evidentiary weight as a document with a measurement methodology attached.

Where this leaves multi-carrier and TMS platforms generally

The split in this research is stark. The nShift family (Ship and Track, Webshipper) publishes the most rigorous documentation found: named percentages, explicit exclusions, and in Webshipper's case, a stated remedy where uptime is measured over each calendar month with a sliding-scale fee reduction if missed. Large US shipping-API platforms like EasyPost publish round marketing numbers repeated across dozens of comparison pages, but the underlying contractual document, if one exists, wasn't found in public search results. Enterprise TMS vendors, including MercuryGate/Infios, Oracle TM, SAP TM, Descartes, Blue Yonder, Alpega, and 3Gtms, publish essentially nothing citable on uptime at all, which is notable given how central these systems are to shipper operations.

This is a gap you can use in your own procurement conversations. If you're evaluating Cargoson alongside nShift, EasyPost, or ShipEngine, ask each one for the same document nShift already publishes rather than accepting a percentage pulled from a homepage or a review thread.

Method and caveats

Figures in this post were collected from vendor documentation, comparison pages, and monitoring services between June and September 2026, and are current as of 22 September 2026. Every percentage traces to a named source in the table above; where no source document could be located, the cell reads "Not published" rather than an estimate. This benchmark does not cover regional latency breakdowns, sandbox-versus-production uptime differences, or carrier-side (as opposed to platform-side) outages, which is a separate and considerably larger dataset given how many hundreds of carrier networks sit behind these platforms.