AutoPosting Pro
// SYSTEM STATUS

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 rather than declared: most of them when the page renders, and the one outbound check that costs us money to run carries its own timestamp so you can see how old it is. The rows use counts and timestamps rather than a word like healthy. Those measurements are still limited to what reached our servers; they do not observe a customer’s local Chrome run or Facebook’s browser acceptance in real time.

Measured 09-06 20:39 UTC · refreshed at most once a minute

Measured now

Six server-side measurements, with the limits of each one stated below.

Web app and database

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.

Responding · 180 ms
Most recent successful sign-in

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.

09-06 20:16 UTC
Hosted inventory/config runs, last 24h

These are hosted worker records, not proof that a customer-local Chrome reader completed or that a browser accepted its result. The hosted service helps build and repair site configurations; local collection has its own evidence and validation.

44 across 7 dealerships
Listing outcomes recorded, last 24h

Recorded after a customer machine reports an outcome. This page did not observe the browser steps or Facebook acceptance directly; if an app cannot reach us it reports neither, so 0 and 0 can mean silence.

54 published · 0 reported failures
Most recent desktop check-in

The last time any customer machine anywhere phoned home. It does not mean yours did — check your own portal for that.

09-06 20:39 UTC
AI description writer · OpenAI · authoritative

A real request to the same provider selected for captions, sent from our servers and paid for by us. OpenAI is authoritative whenever it is configured; GLM appears here only when OpenAI is not configured, and an OpenAI failure never falls through to a second green probe. It still cannot tell you whether one particular listing was written by the model or by our template fallback.

Answered · 1979 ms

Most recent hosted inventory/config run: 09-06 20:29 UTC

AI writer last probed: 09-06 20:39 UTC · successes cached 15 min · failures 5 min

What this page cannot see

The honest half. A customer workflow can be broken while the server measurements above look normal.

  • Facebook inside the customer’s browser. This page cannot watch Marketplace accept a listing, expose a Renew or Delete control, or throttle a particular account. It can display a later report that reached our server, but that is not the same as observing the browser action live.
  • Your dealership specifically. Most counts above aggregate multiple customers. One store can be broken without moving those totals enough to reveal the problem.
  • The customer-local inventory run. The site-specific reader works inside the customer’s Chrome profile. This page does not see its page-by-page progress, local validation or browser permission state. It sees only evidence or a candidate that later reaches the cloud, where incomplete or unsafe results can be held instead of replacing last-known-good inventory.
  • Our outside dependencies. Stripe, email delivery, the Meta Graph API, and GitHub. The AI writer used to be on this list, and that was the whole problem: a dead model writes no rows anywhere, so this page stayed green straight through an outage that was putting template copy into real listings. It has a measured row of its own now. The rest of this list does not, and a failure in any of them still looks like nothing from here.
  • Our hosted configuration and repair worker. It helps build or repair the site-specific reader; it is not the customer’s main inventory executor. It reports only when it has hosted work, so this page cannot distinguish an idle worker from one that is unavailable or infer whether a local Chrome scan is currently running.
  • 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.

Resolvedsome customersBackfilled

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)

Resolvedall customersBackfilled

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.