EntryProof Status

Current deploy: 439cf10 (production). Programmatic access: /cpsc-efile/status.json.

Why we publish this page

EntryProof exists to tell importers whether their listings are actually ready for the CPSC's mandatory eFiling rule before a container gets held at the port. A readiness checker that is silently down when someone runs it produces the worst possible outcome: a false sense of confidence that nothing was actually checked. This page exists so that trust in EntryProof's own availability is not something we ask importers to take on faith — it is something anyone can verify directly, updated hourly, with no login required.

Every row on this page comes from an automated probe that runs once an hour against the systems EntryProof actually depends on: the API layer, the readiness checker itself, the Supabase database, and Resend email delivery. None of these numbers are entered or adjusted by hand after the fact. The cron job that writes them is the same job that would need to lie to make a bad day look clean, and it is not built with that option.

Our uptime target

EntryProof targets 99.5% uptime per calendar month across its core systems, the same SLO threshold used internally across the Digital Empire portfolio's monitoring. That is roughly 3.6 hours of allowed downtime across an entire month, spread across every subsystem combined rather than budgeted separately per subsystem. A single bad hour on one subsystem is not, by itself, treated as a crisis; what matters is whether that budget actually runs out across the month, which is the signal that something structural needs attention.

We chose 99.5% rather than a more impressive-sounding 99.9% or 99.99% on purpose. EntryProof is a young, free-tier product operated by a very small team, and a status page that quietly promises five-nines reliability it cannot realistically staff around is worse than an honest, lower number backed by 90 real days of data. Publishing that history, not just a green dot on any given day, is the entire point of this page.

How we detect problems

The hourly probe checks four things independently: whether the API responds correctly, whether the readiness-checker surface is reachable, whether the database answers a read, and whether Resend is reachable and authenticated. Each check is time-boxed to four seconds so one slow dependency cannot silently hang the others, and a failure in one subsystem never gets masked by success elsewhere. The component grid above always reflects each subsystem's own real, independent result.

An internal SLO check runs on the same hourly cadence, tracking checkout latency, error-handler coverage, and email delivery success rate that this public page does not surface directly, because those are engineering-facing metrics rather than importer-facing availability. When that internal budget is exhausted, it triggers an alert independent of whatever this page currently shows.

Degraded vs. outage: what the colors mean

A yellow "Degraded" mark means a subsystem responded, but slower or with a dependency flagged (for example, Resend or Stripe not configured for that environment) rather than a hard failure. A red "Outage" mark means the probe could not get a valid response at all within its four-second timeout. We keep these two states visually and semantically distinct on purpose, because collapsing them into one generic "not green" state would hide the difference between EntryProof running slow and EntryProof not running.

What we do not yet publish

This page does not yet break out per-region latency or a public API-rate-limit dashboard, both of which larger status pages sometimes include. For a product at EntryProof's current stage, those would add visual complexity without adding real signal. The four data points above (four subsystems, 90 days of history, and an honest incident list) are the ones that actually answer "is EntryProof working right now," and we would rather ship those well than ship a dashboard that looks more sophisticated without being more useful.

Our incident response process

When a subsystem check fails, it appears in the component grid above within the hour it happened, with no manual step required to make it visible. If a failure persists past a single check cycle, it shows up in the incident history section with the date and the percentage of that day's checks that actually passed, so a brief blip and a sustained outage read differently rather than being flattened into one red mark.

Anyone who subscribes to updates gets an email the moment a subsystem's status changes, in either direction. We do not currently maintain a separate incident postmortem page; for a small-team product at this stage, the honest commitment we make is that this status page and its 90-day history will always reflect what actually happened, and that additional process gets built on top of this foundation as EntryProof grows, not promised ahead of having the team to deliver it.