TariffWatch Status
By Andy Gaber, Founder · Published August 13, 2026 · Last updated August 13, 2026
Component status
90-day uptime history
73.16% average uptime across the last 90 days.
Incident history (last 90 days)
- 2026-08-13: Outage on at least one subsystem (60% of checks that day passed).
- 2026-08-14: Outage on at least one subsystem (60% of checks that day passed).
- 2026-08-15: Outage on at least one subsystem (60% of checks that day passed).
- 2026-08-16: Outage on at least one subsystem (78.4% of checks that day passed).
- 2026-08-17: Degraded on at least one subsystem (80% of checks that day passed).
- 2026-08-18: Degraded on at least one subsystem (80% of checks that day passed).
- 2026-08-19: Degraded on at least one subsystem (80% of checks that day passed).
- 2026-08-20: Degraded on at least one subsystem (80% of checks that day passed).
- 2026-08-21: Degraded on at least one subsystem (80% of checks that day passed).
Subscribe to updates
Get an email when TariffWatch's status changes — degraded subsystems, outages, and resolutions.
Current deploy: 439cf10 (production). Programmatic access: /tariffwatch/status.json.
Why we publish this page
TariffWatch exists to tell importers how exposed they are to the proposed Section 232 aluminum and steel duties, and to help them draft a real public comment before the BIS window closes. That is a time-boxed, legally-consequential task. If the exposure checker or comment-letter drafter is silently down during the comment window, the cost to an importer is not an inconvenience, it is a missed deadline. This page exists so that whether TariffWatch is actually working right now 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 TariffWatch depends on: the API layer, the exposure checker, the Supabase database, Resend email delivery, and the regulations.gov integration the comment-letter flow ultimately points at. 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
TariffWatch 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 during the live comment window, which is the period this product is under the most real-world time pressure.
We chose 99.5% rather than a more impressive-sounding 99.9% or 99.99% on purpose. TariffWatch is a young, comment-window-driven 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 five things independently: whether the API responds correctly, whether the exposure-checker surface is reachable, whether the database answers a read, whether Resend is reachable and authenticated, and whether the regulations.gov API is reachable for the docket TariffWatch tracks. 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 checker latency, PDF-generation reliability, and letter-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, the regulations.gov API key or Resend 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 TariffWatch running slow during a comment-window traffic spike and TariffWatch not running at all.
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 — which matters most for TariffWatch during the live BIS comment window, when a delay in the comment-letter drafter has a real deadline attached. 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.