siax.repo.json: operationalState"running" → "down". siax.repo.v3.json: operationalState"degraded" → "down".
Both files' domains[].purpose now record the probe that motivated it.
Nothing else. No DNS, no deploy, no provider setting was touched.
siax.repo.json claimed "running". That was already false on
2026-09-04, when siax.repo.v3.json was set to "degraded" on the
strength of 0pt.app/api/health still answering 200 while api.0pt.app 404'd. That partial-life reading no longer holds: the
Vercel deployment now answers 402 DEPLOYMENT_DISABLED on every
path including /api/health and /api/ready. Nothing 0PT publishes
serves traffic, so both descriptors say down.
The two files disagreeing with each other was itself part of the
problem, so both move together.
Second-order note, not fixed here
0pt.app being on Vercel at all contradicts the self-hosted-EU posture
the rest of the estate is built on (docs/runbook/deploy.md already
says the edge plane is "Live on Vercel, NOT on the SIAX fleet"). This PR
only makes the descriptor honest about it — deciding whether 0PT should
be re-homed onto the fleet, and whether the disabled Vercel deployment
is a billing state or a deliberate one, is Simon's call, not a
descriptor edit.
## What changed
`siax.repo.json`: `operationalState` `"running"` → `"down"`.
`siax.repo.v3.json`: `operationalState` `"degraded"` → `"down"`.
Both files' `domains[].purpose` now record the probe that motivated it.
Nothing else. No DNS, no deploy, no provider setting was touched.
## The measurement
Taken 2026-09-07, both public 0PT hosts are dead:
```
$ curl -sSI https://0pt.app/
HTTP/2 402
cache-control: public, max-age=0, must-revalidate
content-type: text/plain; charset=utf-8
server: Vercel
x-vercel-error: DEPLOYMENT_DISABLED
$ curl -sS -o /dev/null -w "%{http_code}\n" https://0pt.app/api/health
402
$ curl -sS -o /dev/null -w "%{http_code}\n" https://0pt.app/api/ready
402
$ curl -sSI https://api.0pt.app/health
HTTP/2 404
server: Vercel
x-vercel-error: DEPLOYMENT_NOT_FOUND
```
Where they resolve:
```
$ dig +short 0pt.app -> 216.150.16.193 216.150.1.1
$ dig +short api.0pt.app -> 216.150.1.129 216.150.16.65
```
Vercel address space, not the Hetzner fleet.
## Why "down" and not something softer
`siax.repo.json` claimed `"running"`. That was already false on
2026-09-04, when `siax.repo.v3.json` was set to `"degraded"` on the
strength of `0pt.app/api/health` still answering `200` while
`api.0pt.app` 404'd. That partial-life reading no longer holds: the
Vercel deployment now answers `402 DEPLOYMENT_DISABLED` on **every**
path including `/api/health` and `/api/ready`. Nothing 0PT publishes
serves traffic, so both descriptors say `down`.
The two files disagreeing with each other was itself part of the
problem, so both move together.
## Second-order note, not fixed here
`0pt.app` being on Vercel at all contradicts the self-hosted-EU posture
the rest of the estate is built on (`docs/runbook/deploy.md` already
says the edge plane is "Live on Vercel, NOT on the SIAX fleet"). This PR
only makes the descriptor honest about it — deciding whether 0PT should
be re-homed onto the fleet, and whether the disabled Vercel deployment
is a billing state or a deliberate one, is Simon's call, not a
descriptor edit.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Both public 0PT hosts are dead as of 2026-09-07:
$ curl -sSI https://0pt.app/
HTTP/2 402 ... server: Vercel ... x-vercel-error: DEPLOYMENT_DISABLED
(identical on /api/health and /api/ready)
$ curl -sSI https://api.0pt.app/health
HTTP/2 404 ... server: Vercel ... x-vercel-error: DEPLOYMENT_NOT_FOUND
siax.repo.json claimed operationalState "running"; siax.repo.v3.json
claimed "degraded" on the strength of a 2026-09-04 probe where
/api/health still answered 200. Neither holds now, so both files move to
"down" and both domain entries record the probe that motivated it.
Also recorded: both names resolve into Vercel address space
(216.150.16.193 / 216.150.1.1 and 216.150.1.129 / 216.150.16.65), not
the Hetzner fleet.
No DNS, deploy or provider setting was touched.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
CODEOWNERS rules
requested review from sax3l 2026-09-07 16:57:27 +00:00
admin
merged commit into main2026-09-07 17:02:48 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
What changed
siax.repo.json:operationalState"running"→"down".siax.repo.v3.json:operationalState"degraded"→"down".Both files'
domains[].purposenow record the probe that motivated it.Nothing else. No DNS, no deploy, no provider setting was touched.
The measurement
Taken 2026-09-07, both public 0PT hosts are dead:
Where they resolve:
Vercel address space, not the Hetzner fleet.
Why "down" and not something softer
siax.repo.jsonclaimed"running". That was already false on2026-09-04, when
siax.repo.v3.jsonwas set to"degraded"on thestrength of
0pt.app/api/healthstill answering200whileapi.0pt.app404'd. That partial-life reading no longer holds: theVercel deployment now answers
402 DEPLOYMENT_DISABLEDon everypath including
/api/healthand/api/ready. Nothing 0PT publishesserves traffic, so both descriptors say
down.The two files disagreeing with each other was itself part of the
problem, so both move together.
Second-order note, not fixed here
0pt.appbeing on Vercel at all contradicts the self-hosted-EU posturethe rest of the estate is built on (
docs/runbook/deploy.mdalreadysays the edge plane is "Live on Vercel, NOT on the SIAX fleet"). This PR
only makes the descriptor honest about it — deciding whether 0PT should
be re-homed onto the fleet, and whether the disabled Vercel deployment
is a billing state or a deliberate one, is Simon's call, not a
descriptor edit.
🤖 Generated with Claude Code