System status
This page has no uptime percentage on it. Not because the number is bad — because it does not exist. Nothing here has been measured for availability by anyone, least of all by me, and a status page whose first act is to invent the figure it was built to report would be a strange thing to publish from a company that sells the detection of exactly that.
What follows instead: what each component is, what state it is in — stated by me, since the repository is not public, so read these rows as a declaration rather than something you can go and verify — an incident record that is open and empty, and the terms under which real measurement starts.
What this page is
The status page is a static file. Every route on this site is rendered to HTML before anyone requests it, and this one is no exception: it was written to disk at build time and has not run a line of code since. It cannot poll anything. It cannot check whether the server is answering. It does not know what time it is.
The only availability evidence this page can offer is that you are reading it. That means the static tier served at least one request successfully — yours, once, just now. It is a sample of 1, it says nothing about the minute before or the minute after, and it is worth stating plainly because it is the entire extent of what a prerendered status page honestly knows.
A status page that refreshed itself would need a server to ask, and that server would be one more component of mine reporting on my own components. The components section explains why I would rather not solve it that way.
Availability
Four readouts. All four are empty, and they are the honest state of this site's availability record rather than a placeholder for something arriving shortly.
NOT YET MEASURED
Rolling 30-day availability of the prerendered site, as observed from outside my own infrastructure.
NOT YET MEASURED
Rolling 30-day availability of POST /api/waitlist — the one route on this site that runs code rather than serving a file.
NOT YET MEASURED
Time to first byte from an external checkpoint. No checkpoint exists, so no distribution exists to take a median of.
NOT YET APPOINTED
The third party that would run the checks above and publish what it saw. None has been engaged.
Why the figure has to come from someone else
Writing my own uptime monitor would take an afternoon, and the number it produced would be worthless — not wrong, necessarily, but worthless, because it would be a claim by an interested party about its own conduct, with the raw data held by that same party.
That structure has a name on this site. It is the shape the feed battery exists to refuse: an intermediary whose own systems produce the record of how well its own systems behaved, so the only people who can check the claim are the people making it. I spend my time arguing that a broker's self-published feed statistics are not evidence. A vendor's self-published uptime is the same shape, and I do not get an exemption for being the vendor.
So the commitment is specific
- The checks are run by a third party. Not by code in this repository, not on my infrastructure, and not on a schedule I can quietly adjust after a bad week.
- The raw check log is published, not just the summary. A rolling percentage is a lossy compression of the thing that matters. Ninety-nine point nine percent hides a two-hour outage in the middle of a Tuesday, and the two hours are the part you needed.
- The failures are published too, or none of it is. A record that only accumulates good months is an advertisement with a timestamp on it.
- Until all three hold, these readouts stay empty. An interim self-measured number, however carefully hedged, would teach a reader that a number on this page can be an estimate. It cannot.
The components
Five of them, and one absence. The state column below is a fact about the repository that produced this build — what the component is, and how it behaves when the thing it depends on is missing. None of it is an availability claim.
Each component, what it does, and the state establishable from the repository. No row asserts availability.
| Component | What it is | State |
|---|---|---|
| Static pagesThe site itself | Every route is rendered to HTML at build time and served as a file. Nothing on a page is computed when you load it. | Built. This page is one of them — it existed on disk before you asked for it. |
| Waitlist endpointPOST /api/waitlist | The only route that runs code. It takes an email address, and a name and one answer where the visitor gives them, and stores them in first-party key-value storage with the moment it arrived, the page it came from and whether the signup notification went out; nothing else. | Fail-closed. With no storage binding it answers 503 and says so, rather than accepting an address it cannot keep. One path does return success without a write: a submission that fills the hidden honeypot field is answered as if accepted and stored nowhere — that is deliberate, and it is the only one. |
| Search indexPowers /search/ | Rebuilt from the finished pages after every build, served as static files, and queried entirely inside your browser. | Derived from the built site, so it can only return pages that exist. Which pieces of the index it fetches follows from your words, and nothing you type is sent anywhere else. |
| FeedsRSS and JSON Feed | The research feeds, generated from the same content collection that builds the research pages. | Generated, not hand-maintained — so a feed entry cannot describe an article that is not there. |
| Machine endpointsFor retrieval systems | A plain-text site summary, a line-delimited corpus and an RDF dump, all built from the same collections as the pages. | Generated on the same rule as the feeds. What a language model reads here is what a person reads on the page. |
| Independent monitoringThe absence | An external service that fetches the components above on a schedule and publishes the result, including the failures. | NOT YET ENGAGED |
One qualification on the waitlist row, because it is the row a reader is most likely to care about: the storage binding is declared in this repository's deployment config, but whether the deployed worker is currently holding that binding is not something a page baked at build time can see. What the code guarantees is the behaviour on failure — a refusal with a reason, never a thank-you over a dropped address. What it cannot guarantee from here is that today the answer is yes.
Incident record
0
No incident has been recorded. Read that as what it is: a record that was opened recently, kept by the party it reflects, and never once fed by an independent watcher. An outage that began and ended between two of my own page loads would leave no trace here at all.Zero recorded is not zero occurred, and the day those two can be told apart is the day a third party starts checking.
What an entry will carry when there is one
The fields below are the format, not a template waiting to be filled with something already known. There is nothing pending.
- Opened, and closed. Both timestamps in UTC, to the minute.
- Detected by. Whether the monitor caught it, I caught it, or a visitor told me — and if it was a visitor, that is stated, because the gap between those three is a measurement of how well I watch.
- Component. Which row of the register above was affected.
- What a visitor experienced. Described from the outside, not as an internal error code.
- Cause. The actual one. Not "a configuration issue".
- What changed so it cannot recur that way. Usually a build rail, since a fix holds until someone forgets and a rail does not.
Entries are appended. An entry found to be wrong gets a dated correction beneath it rather than a quiet edit, on the same rule the site changelog runs under, and for the same reason: a record its author can revise is not a record.
What this page does not establish
Everything on this page comes from the party it reports on, and none of it has been checked by anyone independent.
- It does not establish that the site is up. It was written before you arrived and cannot check anything on your behalf. If a component were failing right now, this page would read exactly as it does.
- It does not establish that nothing has gone wrong. An empty incident record is a statement about my record, and my record has never had an independent monitor pointed at it.
- It does not establish that the waitlist is accepting addresses today. The endpoint's refusal behaviour is guaranteed by its code; the state of its storage binding in the deployed worker is not visible from a prerendered page.
- It is not a service-level agreement. No availability target and no credit mechanism is published here or anywhere on this site, and nothing is for sale yet, so nothing is promised yet. The support page publishes first-response targets by tier, which are a different object from a guarantee and are labelled as such there.
- It is not a security disclosure channel. Reports go to the security route on the contact page, which security.txt publishes in machine-readable form. What does not exist: a bug-bounty programme, a published testing scope, and any response guarantee.
This snapshot
Every value on this page was fixed at the moment the site was built. The stamp below is how you judge whether it is worth anything today.
If that timestamp is old, this page is old, and it will not tell you so on its own. That is a real weakness of building a status page as a static file, and the honest fix is the independent third-party monitor the components register lists as not engaged, rather than a spinner that implies a check just happened.
The gate
The script that releases this site runs the eighteen steps below, in this order, before it releases anything, and stops at the first one that fails. The list is not written here by hand. It is generated from scripts/ship.mjs, the script that runs them, as that file stood at commit d0cc3b5, and the gate holds this page to the script in both directions: a step listed here that the script does not run fails it, and so does a step the script runs that is missing here.
npm run checkastro check (type and syntax validation of the repository)npm run buildbuildnode scripts/csp-hash.mjsCSP hash ratchetnpm run checkverify:all check (the first command of the package script verify:all, which runs astro check again)npm run verifyverify (the content rails over dist/, scripts/verify-dist.mjs)npm run test:gatetest:gate (the unit suite of scripts/tests, one file at a time, after the build so that a test which reads dist can; a test that re-runs a whole prover is left to the step that runs that prover)node scripts/origin-inventory.mjs --checkorigin-inventory check (the crossing manifest judged against the built tree)node scripts/origin-inventory.mjs --self-testorigin-inventory self-testnpm run verify:ledgersverify:ledgers (every entry of the append-only ledgers at HEAD is still there, byte for byte)npm run verify:sourcesverify:sources (the canonical documents against the sha256 pins in DECISIONS.md)node scripts/verify-canfail.mjsverify-canfail (each rail of verify-dist rejects its poisoned fixture and accepts its clean control)node scripts/ratchet.mjs --checkratchet (the checks, cases, steps and thresholds held to src/data/ratchet.json, each threshold by value and tag: a fall or a loosening is refused unless an entry of DECISIONS.md names it)npm run verify:ledgers:proveverify:ledgers:prove (the ledger check run on its planted cases)npm run verify:bytesverify:bytes (no tracked text file carries a byte order mark or a control byte)npm run verify:bytes:proveverify:bytes:prove (each planted defect rejected, the clean controls accepted)npm run verify:schemaverify:schema (the structured data names only what the page shows, and every node it points at exists)npm run verify:schema:proveverify:schema:prove (every check of verify:schema shown refusing)npm run repair:mirrors:proverepair:mirrors:prove (the heading-parity repair proved on planted cases)
A passing gate says the build met these steps. It does not say the site is up: that is the availability record above.