What we can actually see, right now.
This page used to be a green dot that said all systems operational. It was a hardcoded string — it said that during an outage too, which is exactly when someone checks. We deleted it and built this instead. Every number below is measured when the page renders, and every one of them is a count or a timestamp rather than a word like healthy. A timestamp cannot be wrong.
Measured 08-12 01:44 UTC · refreshed at most once a minute
Measured now
Five things our servers can observe directly.
A real query round-trip to our production database, run as this page rendered. Proves the app and database are up. Proves nothing else on this page.
Someone completed a full sign-in, including the emailed code. This is our strongest end-to-end signal — it means auth and outbound email both worked at that moment.
Accepted is not the same as correct. Our guards reject snapshots that shrink suspiciously, and those rejections are counted separately rather than hidden.
Reported by customer machines, so read these two numbers together. If an app cannot reach us it reports neither — 0 and 0 means silence, not health.
The last time any customer machine anywhere phoned home. It does not mean yours did — check your own portal for that.
Most recent inventory sync: 08-12 00:51 UTC
What this page cannot see
The honest half. Everything here could be broken while every number above looks fine.
- Facebook itself. Whether Marketplace is accepting listings today, and whether a specific account has been throttled. We have no signal for this and neither does anyone else selling you this category of software.
- Your dealership specifically. Every number above spans all customers. One store being completely broken for three days would not visibly move any of them.
- Whether your scraper still reads your site correctly. If your website changes, a scraper can return half your lot and still record a perfectly successful sync.
- Our outside dependencies. Stripe, email delivery, the Meta Graph API, our AI provider, and GitHub. A total AI outage writes no rows anywhere, so this page would stay green straight through one.
- Our scraper-build worker. It runs on hardware we host ourselves and only reports in when it has work to do, so a healthy idle worker and a dead one look identical from here. We would rather say that than show you a row we cannot stand behind.
- Its own worst outage. This page is served by the infrastructure it describes. If that is down you will not see red — you will see nothing.
If your posting is broken and this page looks fine, both can be true. Email [email protected] and it reaches a person.
Incident history
We started keeping this record on 2026-08-11. Entries marked backfilled predate it and were reconstructed from our commit history, so their times are recorded to the day. This list is append-only — corrections get appended and dated, never edited away.
A stuck Chrome window could freeze a desktop posting queue indefinitely
On affected machines the posting queue stopped moving and stayed stopped — no error, no timeout, no recovery until the app was force-quit. Delisting was the most common trigger.
- Impact began
- 2026-08-11
- We noticed
- 2026-08-11
- Resolved
- 2026-08-11
What caused it. The desktop app held a lock while waiting on a browser command that had no time limit. If Chrome stopped responding, the wait never ended and every other queued job waited behind it forever.
What changed. Every browser command now has a hard time limit, and the lock is acquired with a timeout instead of waiting indefinitely, so one wedged window fails its own job and releases the queue. Shipped in desktop v2.5.80. (8e9d39c)
Sign-in, portal and inventory sync unavailable
Customers could not sign in, the portal would not load, and inventory syncs were rejected — all at the same time.
- Impact began
- 2026-07-08
- We noticed
- Not recorded
- Resolved
- 2026-07-08
What caused it. Our production database connection was configured in a mode that caps total connections. A handful of warm serverless instances used up the whole allowance, and every request after that was refused.
What changed. Production moved to the pooling mode built for serverless, with an explicit per-instance connection limit. We also added the /api/health probe this page is built on, so the same failure now trips a monitor instead of degrading silently.
There is deliberately no uptime percentage here. Computing one honestly needs a denominator that includes every outage nobody reported, and we do not have that. A number we cannot stand behind is how this page went wrong the first time.