Uptime, latency, and webhook dispatch — computed from recorded request telemetry over a rolling window. Nothing here is estimated or simulated.
Delays a carrier has posted, with the carrier's own estimate of the days they add. A quote or shipping estimate into a state or ZIP named here answers its delivery date as at risk.
No component has recorded enough traffic over the full 90-day window to read an uptime from yet; the bar shows the requests that were recorded. Uptime counts observed days only — a day with no recorded traffic is not counted as healthy.
Each component is measured over its own recorded traffic across the last 90 days; its bar draws the last 30. A component with nothing recorded reads “no data”, and one with fewer than 100 requests in the 90 days “not enough traffic to measure” — below that, one server error moves its rate past the 1% line. From 100 up, a component reads the worse of its 90-day error rate and its rate over the last day once that day holds 100 requests of its own, so weeks of successes do not dilute a fresh partial failure; its bar and uptime stay the 90-day reading. Two things are an outage at any volume, read off the last day so that an incident long resolved is not one: every request failing with a server error, or (below 100) 5 server errors. Sandbox-key requests count, our scheduled smoke test's among them, and each row says how many — but a row is also read from its live requests alone, and the worse reading stands, because a sandbox order never reaches a plant. An outage that leaves orders going through is a partial one; before any live order, sandbox orders are the orders measured. Webhook dispatch measures what we control: that each event is signed, sent and retried on schedule. A subscriber's endpoint answering an error, timing out or failing DNS is that endpoint's result — its owner sees the cause in their delivery log — and is not counted here.
Order submission, lifecycle and cancellation — the endpoints that reach the plants
Signing and sending each event, the retry queue, and the endpoints that manage subscriptions. A subscriber's own endpoint failing is not counted here
Each operation measured on its own over the last 30 days, by the name the MCP tool gives it, from the same recorded requests as the rows above.
quote_orderQuote an order · POST /v1/orders/quote
create_orderPlace an order · POST /v1/order
Monthly uptime objective
99.9%
Every account runs on the same infrastructure, held to the same objective.
Production target
24 hours
Order submission to shipped, standard catalog products.
Latency objective
Measured, not promised
The p50 / p95 / p99 above are computed from real traffic.
We publish measured p50/p95/p99 latency from real traffic on the status page rather than a latency objective. A number you can check is worth more than a number we choose. The history above counts observed days under the error threshold — a day-granularity view of the recorded telemetry.
Degradation windows recorded by the platform's own detectors — opened when a subsystem fails, closed when it recovers.
No degradations recorded in the last 30 days. (This is what we measured about ourselves — silence here means nothing was recorded, not a guarantee.)
GET https://portal.printedsimply.com/api/status answers this page's numbers with no key, to any origin, recomputed at most once a minute and limited to 60 requests a minute per IP address. overall and each services[].status is operational, degraded, outage, insufficient_data or no_data, by the rules above: insufficient_data is fewer than minSamples requests over 90 days with neither every request of the last day failed nor 5 server errors in it, and an overall of degraded can be a partial outage — a service at outage while orders go through. Each service carries the sample its tier was read from — requests, of which sandboxRequests used sandbox keys — with errorRate, latency and uptime over 90 days, and requestsByDay draws the 30-day bars. operations carries quote_order and create_order measured alone over 30 days — requests, sandboxRequests and a latency that is null where nothing was recorded. uptime and uptime30d, each service's and the top level's (every component together), are null where nothing was recorded and where the sample is too small to read a tier from.
Be notified of incidents and maintenance windows.
Last updated: October 23, 2026 at 3:57 AM
Running commit d27010b099a6
Uptime, error rate and latency are computed from recorded request telemetry over a rolling 90-day window; webhook dispatch over the trailing 30 days. Nothing here is estimated or simulated, and a window with nothing in it reads “no data” rather than 100%.
Product, pricing and shipping reads, and the sync that keeps them current
Every other v1 endpoint