Skip to content
OpenRegs
Service statusNot yet reporting

Status

This page will report on OpenRegs Cloud. Nothing on it is wired to a live check yet, so every service below reads “not reporting” — which is a different statement from “fine”, and the page is built so the two cannot be confused.

Nothing here is being monitored yet

No row below is fed by a live check, so this page cannot tell you whether these are working. It says so rather than showing you a tick.

Services

  • Query API

    Not reporting

    The authenticated endpoint an agent or a service calls — POST /v1/answer and POST /v1/unit, and the MCP surface beside them.

    No API endpoint has been published and nothing is open for signup, so there is no address whose availability would mean anything to you and no key that would reach one.

  • Console

    Not reporting

    Where an organisation would manage its keys, its members and its usage.

    Not built. API keys are minted by hand into a file an operator holds, so there is no console whose availability would mean anything.

  • Verified serving

    Not reporting

    Whether what is being served was verified before it was served — the property the hosted product exists to sell.

    The check is real and runs continuously inside the deployment: every fifteen seconds the control plane asks a running instance what its answers are stamped with, and refuses to route to one stamping anything but verified. That reading is deliberately not repeated here. Taken when this page was last built, it would put a stale timestamp beside a reassuring word — the exact failure this page exists to avoid — and nothing outside the service is watching it yet in any case.

  • This website

    Not reporting

    openregs.io, including the page you are reading.

    Not monitored — and this page could not tell you if it were. It is served by the same host as the rest of the site, so an outage takes the status page with it. A status page that shares a failure domain with its subject is decoration.

Verification posture, per regime

The hosted product's promise is that a release was verified before anything was served from it, so the posture each regime is being served under belongs on this page beside its availability. A response carries one of three stamps — verified, meaning all five checks passed before the server bound a socket; digests, an unsigned local build; and skipped, verification waived.

  • fixreg — Fixture Regulation (EU) 2024/1

    Fixture · fixreg@2025.04

    Not reporting

    A deployment is serving this fixture and reporting a verified posture, and that reading is held back here for the reason above: dated from the last build, it would say more than it knows. The fixture is synthetic throughout and deliberately about nothing; it exists so the test suite can assert against a corpus whose every digest is known.

One row, and it is a fixture. No body of real law has been published, so there is no regime here whose posture would tell you anything about the law you are subject to. What exists and what does not.

Where the readings will come from

Naming the signals now is the point of publishing the page early: when a row here goes from “not reporting” to a state, you should be able to see which probe changed its mind.

GET /readyz
The engine answers 503 here until a verified release is loaded, and so does every other route with it. It is the difference between a process that has started and a process that is serving law, and it is what traffic is routed on.
GET /v1/status
The control plane already answers this: the engine version, the schemas, the disclaimer and the release it pins, plus the verification stamp it last observed a running instance actually serving under. It is the intended source for the rows above, and what is missing is not the signal. Three other things are: a published service worth reporting on, something watching it that is not this page, and a way of reading that cannot present the last build's answer as this minute's.

What this page does not have

  • No monitoring behind it. Not merely that this page is unwired — nothing else is watching either. No uptime monitor, no alerting, nobody on call. The one check that does run is the service inspecting itself from the inside: the control plane asks the engine every fifteen seconds what its answers are stamped with, and stops routing to it if the answer is ever anything but verified. That is a good check and it is not the same thing as somebody noticing the whole service has stopped answering.
  • No uptime figure. A percentage is a measurement over a window, and no window has been measured. The number that would go here would be invented.
  • No incident history. Not a claim that there have been no incidents — a claim that there has been no service to have them.
  • No uptime commitment. Availability targets and the freshness promise — how fast a change at the regulator reaches a release you can query — are both deliberately unset, because neither can be committed to before it has been measured.
  • No subscribe button. There are no notifications to sign up for yet. The Cloud waitlist is the only list, and it is for availability rather than incidents.