Mätt live 2026-09-25 mot produktionsdeployen 0pt.app / api.0pt.app (container shxd6lepxuxfsjsp0ath3z1g-172514162615, server6, uppe 17,9 h, Docker-status healthy hela tiden):
GET /api/health -> HTTP/1.1 200 OK
{"ok":false,"service":"0pt-web","db":"ok","queue":"not_configured",
"engine":"error","stripe":"not_configured",
"detail":{"engine":"This operation was aborted"}}
GET /api/ready -> HTTP/1.1 200 OK
{"ready":true,"service":"0pt-web","db":"ok","engine":"error",...}
ENGINE_URL pekade på http://0pt-engine:8000. Mätt inifrån containern:
engine host: http://0pt-engine:8000 creds-in-url: false
getent hosts 0pt-engine -> ingen post
fetch ENGINE_URL/health -> ERR fetch failed after 5069 ms
Och det finns ingen container vid namn 0pt-engine på någon av server5–server11.
Datamotorn — 0pt:s hela produkt — var alltså borta, och varje signal ovanför den var grön: Docker healthy, /api/health 200, /api/ready 200. ok:false i en 200-kropp är ingen signal; ingenting i kedjan läser kroppar, allt läser statuskoder och exitkoder.
Vad ändringen gör
isReady skilde tidigare bara på db.status === "ok". Den skillnad som saknades är inte konfigurerad vs ej konfigurerad utan frånvarande vs trasig:
status
betydelse
readiness
not_configured / not_integrated
ingen bad om integrationen
fortsatt ready — 0pt är byggt för att köra utan motor/Stripe/kö
error
någon konfigurerade den och en riktig round trip mot den misslyckades just nu
inte ready
En konfigurerad-men-död motor är inte en "valfri integration" längre. Någon har bett om den och den svarar inte.
Vad ändringen INTE gör
Ingenting i driften ändras i dag. Container-HEALTHCHECK pekar på /api/health (liveness), och Dockerfilen säger uttryckligen att en readiness-probe inte ska peka dit — det respekteras, Dockerfilen är orörd. Den här ändringen gör bara den ärliga ytan faktiskt ärlig, så att en yttre övervakning kan använda den.
Rekommendation som ligger utanför det här repot
Coolifys /api/health-probe för 0pt.app bör kompletteras med en uptime-övervakning mot /api/ready. Det är en driftkonfiguration, inte en kodändring, och den lämnas till Simon.
Verifiering
Regressionstest tillagt i tests/lib/health-checks.test.ts. Verifierat i båda riktningar:
mot den gamla isReady: 1 failed | 18 passed
mot den nya: 24 passed över health-checks + ready + health
npx eslint rent på de ändrade filerna. npx tsc --noEmit visar samma redan existerande fel som på main (tests/auth/*, tests/p0/decision-er-shadow.test.ts) — inga i de filer den här PR:en rör.
## Vad som var fel (mätt, inte antaget)
Mätt live 2026-09-25 mot produktionsdeployen `0pt.app` / `api.0pt.app` (container `shxd6lepxuxfsjsp0ath3z1g-172514162615`, server6, uppe 17,9 h, Docker-status `healthy` hela tiden):
```
GET /api/health -> HTTP/1.1 200 OK
{"ok":false,"service":"0pt-web","db":"ok","queue":"not_configured",
"engine":"error","stripe":"not_configured",
"detail":{"engine":"This operation was aborted"}}
GET /api/ready -> HTTP/1.1 200 OK
{"ready":true,"service":"0pt-web","db":"ok","engine":"error",...}
```
`ENGINE_URL` pekade på `http://0pt-engine:8000`. Mätt inifrån containern:
```
engine host: http://0pt-engine:8000 creds-in-url: false
getent hosts 0pt-engine -> ingen post
fetch ENGINE_URL/health -> ERR fetch failed after 5069 ms
```
Och det finns ingen container vid namn `0pt-engine` på någon av server5–server11.
**Datamotorn — 0pt:s hela produkt — var alltså borta, och varje signal ovanför den var grön:** Docker `healthy`, `/api/health` 200, `/api/ready` 200. `ok:false` i en 200-kropp är ingen signal; ingenting i kedjan läser kroppar, allt läser statuskoder och exitkoder.
## Vad ändringen gör
`isReady` skilde tidigare bara på `db.status === "ok"`. Den skillnad som saknades är inte *konfigurerad vs ej konfigurerad* utan **frånvarande vs trasig**:
| status | betydelse | readiness |
|---|---|---|
| `not_configured` / `not_integrated` | ingen bad om integrationen | fortsatt ready — 0pt är byggt för att köra utan motor/Stripe/kö |
| `error` | någon konfigurerade den **och** en riktig round trip mot den misslyckades just nu | **inte ready** |
En konfigurerad-men-död motor är inte en "valfri integration" längre. Någon har bett om den och den svarar inte.
## Vad ändringen INTE gör
Ingenting i driften ändras i dag. Container-`HEALTHCHECK` pekar på `/api/health` (liveness), och Dockerfilen säger uttryckligen att en readiness-probe inte ska peka dit — det respekteras, Dockerfilen är orörd. Den här ändringen gör bara den ärliga ytan faktiskt ärlig, så att en yttre övervakning kan använda den.
## Rekommendation som ligger utanför det här repot
Coolifys `/api/health`-probe för `0pt.app` bör kompletteras med en uptime-övervakning mot `/api/ready`. Det är en driftkonfiguration, inte en kodändring, och den lämnas till Simon.
## Verifiering
Regressionstest tillagt i `tests/lib/health-checks.test.ts`. Verifierat i båda riktningar:
* mot den gamla `isReady`: `1 failed | 18 passed`
* mot den nya: `24 passed` över `health-checks` + `ready` + `health`
`npx eslint` rent på de ändrade filerna. `npx tsc --noEmit` visar samma redan existerande fel som på `main` (`tests/auth/*`, `tests/p0/decision-er-shadow.test.ts`) — inga i de filer den här PR:en rör.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Mätt live 2026-09-25 mot produktionsdeployen (0pt.app / api.0pt.app,
container shxd6lepxuxfsjsp0ath3z1g-172514162615 på server6, uppe 17,9 h,
Docker-status "healthy" hela tiden):
GET /api/health -> HTTP/1.1 200 OK
{"ok":false,"service":"0pt-web","db":"ok","queue":"not_configured",
"engine":"error","stripe":"not_configured",
"detail":{"engine":"This operation was aborted"}}
GET /api/ready -> HTTP/1.1 200 OK
{"ready":true,"service":"0pt-web","db":"ok","engine":"error",...}
ENGINE_URL pekade på http://0pt-engine:8000. Mätt inifrån containern:
`getent hosts 0pt-engine` ger ingen post, och det finns ingen sådan
container på någon av server5-11. Ett direktanrop mot motorn misslyckas
efter ~5 s (DNS). Datamotorn — 0pt:s hela produkt — var alltså BORTA, och
samtliga signaler ovanför den var gröna: Docker healthy, /api/health 200,
/api/ready 200.
`ok:false` i en 200-kropp är ingen signal. Ingenting i kedjan läser
kroppar; allt läser statuskoder och exitkoder.
isReady skilde tidigare bara på "db ok". Den skillnad som saknades är inte
konfigurerad-vs-ej-konfigurerad utan FRÅNVARANDE-vs-TRASIG:
* not_configured / not_integrated -> fortsatt ready. 0pt är byggt för att
kunna köra utan motor, Stripe och kö (se .env.example).
* error -> INTE ready. Statusen "error" betyder att någon medvetet
konfigurerade beroendet och att en riktig round trip mot det just
misslyckades. Det är inte längre en valfri integration.
Ändrar ingenting i driften i dag: container-HEALTHCHECK pekar på
/api/health (liveness) och Dockerfilen säger uttryckligen att en
readiness-probe inte ska peka dit. Den här ändringen gör bara att den
ärliga ytan faktiskt blir ärlig, så en yttre övervakning kan använda den.
Regressionstest tillagt; verifierat att det FALLER mot den gamla isReady
(1 failed | 18 passed) och passerar mot den nya (24 passed över
health-checks/ready/health).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
CODEOWNERS rules
requested review from sax3l 2026-09-25 11:35:03 +00:00
Granskad och mergad av plattformssamordningen. Checkar grona (10 st), mergeable, inga rода eller pending vid mergetillfallet.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
admin
merged commit ec487746fd into main2026-09-25 12:42:43 +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.
Vad som var fel (mätt, inte antaget)
Mätt live 2026-09-25 mot produktionsdeployen
0pt.app/api.0pt.app(containershxd6lepxuxfsjsp0ath3z1g-172514162615, server6, uppe 17,9 h, Docker-statushealthyhela tiden):ENGINE_URLpekade påhttp://0pt-engine:8000. Mätt inifrån containern:Och det finns ingen container vid namn
0pt-enginepå någon av server5–server11.Datamotorn — 0pt:s hela produkt — var alltså borta, och varje signal ovanför den var grön: Docker
healthy,/api/health200,/api/ready200.ok:falsei en 200-kropp är ingen signal; ingenting i kedjan läser kroppar, allt läser statuskoder och exitkoder.Vad ändringen gör
isReadyskilde tidigare bara pådb.status === "ok". Den skillnad som saknades är inte konfigurerad vs ej konfigurerad utan frånvarande vs trasig:not_configured/not_integratederrorEn konfigurerad-men-död motor är inte en "valfri integration" längre. Någon har bett om den och den svarar inte.
Vad ändringen INTE gör
Ingenting i driften ändras i dag. Container-
HEALTHCHECKpekar på/api/health(liveness), och Dockerfilen säger uttryckligen att en readiness-probe inte ska peka dit — det respekteras, Dockerfilen är orörd. Den här ändringen gör bara den ärliga ytan faktiskt ärlig, så att en yttre övervakning kan använda den.Rekommendation som ligger utanför det här repot
Coolifys
/api/health-probe för0pt.appbör kompletteras med en uptime-övervakning mot/api/ready. Det är en driftkonfiguration, inte en kodändring, och den lämnas till Simon.Verifiering
Regressionstest tillagt i
tests/lib/health-checks.test.ts. Verifierat i båda riktningar:isReady:1 failed | 18 passed24 passedöverhealth-checks+ready+healthnpx eslintrent på de ändrade filerna.npx tsc --noEmitvisar samma redan existerande fel som påmain(tests/auth/*,tests/p0/decision-er-shadow.test.ts) — inga i de filer den här PR:en rör.🤖 Generated with Claude Code
Mätt live 2026-09-25 mot produktionsdeployen (0pt.app / api.0pt.app, container shxd6lepxuxfsjsp0ath3z1g-172514162615 på server6, uppe 17,9 h, Docker-status "healthy" hela tiden): GET /api/health -> HTTP/1.1 200 OK {"ok":false,"service":"0pt-web","db":"ok","queue":"not_configured", "engine":"error","stripe":"not_configured", "detail":{"engine":"This operation was aborted"}} GET /api/ready -> HTTP/1.1 200 OK {"ready":true,"service":"0pt-web","db":"ok","engine":"error",...} ENGINE_URL pekade på http://0pt-engine:8000. Mätt inifrån containern: `getent hosts 0pt-engine` ger ingen post, och det finns ingen sådan container på någon av server5-11. Ett direktanrop mot motorn misslyckas efter ~5 s (DNS). Datamotorn — 0pt:s hela produkt — var alltså BORTA, och samtliga signaler ovanför den var gröna: Docker healthy, /api/health 200, /api/ready 200. `ok:false` i en 200-kropp är ingen signal. Ingenting i kedjan läser kroppar; allt läser statuskoder och exitkoder. isReady skilde tidigare bara på "db ok". Den skillnad som saknades är inte konfigurerad-vs-ej-konfigurerad utan FRÅNVARANDE-vs-TRASIG: * not_configured / not_integrated -> fortsatt ready. 0pt är byggt för att kunna köra utan motor, Stripe och kö (se .env.example). * error -> INTE ready. Statusen "error" betyder att någon medvetet konfigurerade beroendet och att en riktig round trip mot det just misslyckades. Det är inte längre en valfri integration. Ändrar ingenting i driften i dag: container-HEALTHCHECK pekar på /api/health (liveness) och Dockerfilen säger uttryckligen att en readiness-probe inte ska peka dit. Den här ändringen gör bara att den ärliga ytan faktiskt blir ärlig, så en yttre övervakning kan använda den. Regressionstest tillagt; verifierat att det FALLER mot den gamla isReady (1 failed | 18 passed) och passerar mot den nya (24 passed över health-checks/ready/health). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>Granskad och mergad av plattformssamordningen. Checkar grona (10 st), mergeable, inga rода eller pending vid mergetillfallet.
🤖 Generated with Claude Code