PixelProof Status

Current deploy: 439cf10 (production). Programmatic access: /meta-monitor/status.json.

Why we publish this page

PixelProof exists to tell Shopify merchants the truth about whether their Meta Pixel, GA4, and GTM tracking is actually firing. That only works if merchants can trust PixelProof itself to be reliable — a monitoring product that is silently down defeats its own purpose worse than almost any other category of software, because a merchant relying on it has no independent way to know their tracking broke if PixelProof stopped checking without saying so. This page exists so that trust is not something we ask for, it is something anyone can verify directly against real data, updated hourly, with no login required.

Every row on this page comes from an automated probe that runs once an hour against the actual systems PixelProof depends on: the API layer, the storefront scanner, the Supabase database, Resend email delivery, and the Chrome extension's rules feed. None of these numbers are manually entered or adjusted 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 does not have that option built in. If a check fails, it shows up here within the hour, whether or not anyone has told us about it yet.

Our uptime target

PixelProof targets 99.5% uptime per calendar month across its core systems, the same SLO threshold used internally by our hourly error-budget monitor. That works out to roughly 3.6 hours of allowed downtime across an entire month, spread across every subsystem combined, not 3.6 hours per subsystem. We treat that budget the way most serious infrastructure teams do: a single bad hour on one subsystem is not, by itself, a crisis, it is what an error budget exists to absorb. What we watch for is the budget actually running out, which is the signal that something structural needs to change rather than something that will resolve itself.

We chose 99.5% rather than a headline-friendlier 99.9% or 99.99% deliberately. PixelProof is a young product built and 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 real data. 99.5% is a target we can actually defend against 90 days of history, which is the entire point of publishing history at all instead of just a current green dot.

How we detect problems

The hourly probe checks five things independently: whether the API responds correctly, whether the storefront scanner surface is reachable, whether the database answers a read, whether our email provider is reachable and authenticated, and whether the Chrome extension's signed rules feed is serving a valid, current payload. Each check is time-boxed to four seconds so a single slow dependency cannot silently hang the others, and a failure in one subsystem does not get hidden by success in the rest. The component grid above always reflects each subsystem's own real result, not an average.

We also run an internal SLO check on the same hourly cadence, tracking latency and error-rate targets (landing page response time, scanner API latency, Stripe webhook processing time, email delivery success rate, and Chrome extension rules-fetch success rate) that this public status page does not show directly, because those are engineering-facing metrics rather than merchant-facing availability. When an SLO breach exhausts the monthly error budget, it triggers an internal alert, independent of whether this status page shows red.

Our incident response process

When a subsystem check fails, it appears in the component grid above within the hour it happened, no manual step required to make that 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 short blip and a sustained outage look visibly different from each other rather than being flattened into the same red mark.

Anyone who subscribes to updates gets an email the moment a subsystem's status changes, in either direction, and both degrading and recovering generate a notice, not just the bad news. We do not currently maintain a separate incident postmortem page; for a small-team product at this stage, the honest commitment we can make is that this status page and its 90-day history will always reflect what actually happened, rather than promising a level of incident-communication process we cannot yet staff. As PixelProof grows, this page is the foundation that additional process (postmortems, root-cause writeups) will be built on top of, not replaced by.