fix(descriptor): 0PT operationalState running -> down (measured 2026-09-07) #41

Merged
admin merged 1 commits from fix/descriptor-0pt-operational-state-down into main 2026-09-07 17:02:48 +00:00
Owner

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

## 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)
admin added 1 commit 2026-09-07 16:57:27 +00:00
fix(descriptor): 0PT operationalState running -> down (measured)
CI (SIAX Cloud) / integration (push) Successful in 26s
CI (SIAX Cloud) / quality (push) Successful in 32s
Security Scan (SIAX Cloud) / security (push) Successful in 37s
CI (SIAX Cloud) / security (push) Successful in 37s
Security Scan (SIAX Cloud) / security (pull_request) Successful in 14s
CI (SIAX Cloud) / security (pull_request) Successful in 15s
CI (SIAX Cloud) / integration (pull_request) Successful in 30s
CI (SIAX Cloud) / quality (pull_request) Successful in 56s
8dd85ad7cc
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 main 2026-09-07 17:02:48 +00:00
admin deleted branch fix/descriptor-0pt-operational-state-down 2026-09-07 17:02:48 +00:00
Sign in to join this conversation.
No Reviewers
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: admin/0pt#41