Whether the Sigrix side of Postern is up: the entitlement check your runner calls, the bundle it pulls, the version it compares at boot, and the schemas the protocol's documents point at. Nothing on this page is specific to your account, your token or any listing.
Every subsystem a bought agent depends on is answering.
Checks are being answered from a live read of the entitlement record.
/postern/v0/entitlements/{owner}/{name}
Bundles are being served to entitled buyers.
/postern/v0/bundles/{owner}/{name}
Boot-time update checks are being answered from a live read of the listing.
/postern/v0/versions/{owner}/{name}
All 8 schema documents for Postern 0.1 are resolving.
/schemas/postern/{version}/{filename}
These are the windows Sigrix declares as a distributor, and they are read from the same constants the entitlement endpoint answers with — so the bound published here is the one your runner is actually given. An outage shorter than their sum is one your agent runs straight through.
Postern answers an unknown token, a revoked one, a token replaced by rotation, and an agent
your account does not own identically: 404, with the same body
every time. Anything that separated them would let anyone holding a guess sort guesses into
two piles, which is all an enumeration attack needs. The cost is this page: it can tell you
the check is answering, and it cannot tell you what it answered you.
So every row above can read Operational while your own check returns 404.
If that is what you are seeing, it is your token or your purchase rather than this page:
regenerate your feed token from your account settings — note
that rotating it re-keys your runner too — and check the agent identifier against the one on
the listing.
A 503 is the other half. That one is what the rows above describe, and it
is the answer this distributor gives when a read fails rather than when you are refused —
because a 5xx keeps your agent running and a 404 stops it for good.
Checked at 2026-09-11T07:13:35Z Machine-readable report