TAG platform status

Every service on develop.tag.company, tier by tier, with what was checked, what it answered, and how it has behaved since.

Running, with something degradedchecked 49s ago · 2026-11-09 13:33:12Z← Front door

This page is /status, and it is the only page on this estate that says whether anything is working. / is the way IN — names, purposes and links, and not one claim about health, because a fact with two owners is how this estate keeps being wrong. Machines poll /health, which answers this page as JSON with a status code that means something. The dot on a card at / is this page's verdict rendered again — the same snapshot, the same function — so it is the only claim that page makes and it cannot be a second opinion.

sampledevery 60s, in the background

this observation49s old

history since24m ago

samples stored1,066

survived0 restart(s)

This history starts here. Nothing was found in the store when this container started, so every window below begins at that moment. If this keeps happening after a merge, the volume in health/compose.yaml is not attached and the memory of this page is one deploy long — docs/health-page.md says how to check.

degraded · 1unknown · 16ok · 24not deployed · 3held · 2internal only · 1not checked · 2

Needs attention. These are ours:

Agent fleet dashboard — HTTP 404, expected 200

Web surfaces

degraded · 1ok · 6not deployed · 2held · 2internal only · 1

What a person can open in a browser. Probed THROUGH THE EDGE, at their public paths, so a green card means the routing works and not merely that a container is alive. A route that 404s is the failure this tier exists to catch — it is how /health itself was found missing. One surface here is NOT on this origin and says so on its own row; it is grouped by what a person does, not by where it is served from.

Origin (the TAG app)ok

/aletia

tag-mvp-ux

Under a prefix, which is why the front door can have /: two things cannot own one path. The prefix is compiled into the bundle by Next.js basePath, so it is a rebuild of tag-mvp-ux and not a routing change. See ../docs/nextjs-basepath.md.

14:00Z1 of 24 hours observednow

state: ok for 8m · since 13:24Z
24 hours: not observed that long · 38.5% of 26 so far
7 days: not observed that long · 38.5% of 26 so far
30 days: not observed that long · 38.5% of 26 so far
all time: 38.5% 26 samples · 16 down · observed 24m
response: 82 ms now p50 34 ms p95 139 ms · 26 samples, 24h
changed: 1 time(s) in 24h — a service that flaps is a different problem from one that is down
last failure: 10m ago · down — [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate (_ssl.c:1016)
shipped by: tag-mvp-ux, on its own merge — never from this repository
probe: GET /aletia · reproduce: curl -i https://develop.tag.company/aletia
expects HTTP 200
through the edge
depends on: Edge (Traefik) and TLSKong (API gateway)Dynamic.xyz origin allowlist

HTTP 200 · through the edge · 82 ms

TrueForge chatprotected

/chat

truefoundry/trueforge

Third-party (truefoundry/trueforge, pinned in trueforge/VERSION). BEHIND HTTP BASIC AUTHENTICATION AT THE EDGE since 2026-10-14, because the service itself authenticates nobody: every request, with no credential or with an invalid one, is served as the same `admin` subject, and the session list was readable in full by anyone with the URL. One shared password is not per-user access and not per-client isolation — everyone who has it still sees every conversation in this instance. See ../docs/chat-basic-auth.md.

14:00Z1 of 24 hours observednow

state: protected for 8m · since 13:24Z
24 hours: not observed that long · 38.5% of 26 so far
7 days: not observed that long · 38.5% of 26 so far
30 days: not observed that long · 38.5% of 26 so far
all time: 38.5% 26 samples · 16 down · observed 24m
response: 53 ms now p50 27 ms p95 61 ms · 26 samples, 24h
changed: 1 time(s) in 24h — a service that flaps is a different problem from one that is down
last failure: 10m ago · down — [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate (_ssl.c:1016)
shipped by: this repository — the pin in trueforge/VERSION, the TAG theme and the mark, digested into one image tag
probe: GET /chat/healthz · reproduce: curl -i https://develop.tag.company/chat/healthz
expects HTTP 401
through the edge
depends on: Edge (Traefik) and TLSTrueForge PostgresTrueForge RedisOpenRouter (JEV_API_KEY)

HTTP 401 — the edge refused an anonymous request — nothing behind it was reached · through the edge · 53 ms

TAG Staff (Paperclip)not deployed

${STAFF_URL}

paperclipai/paperclip

Third party (paperclipai/paperclip), pinned by digest in paperclip/DIGEST and themed here. OFF-ORIGIN, which is unique on this page: it is the only surface a person opens that is not served from this host. Flip this row to `deployed` in the commit that brings it up, not before — see ../docs/adding-a-service.md § A service that is not on this origin.

state: not deployed
shipped by: this repository — the upstream digest in paperclip/DIGEST, the TAG theme and the mark, digested into one image tag
depends on: Postgres

Never probed, so there is nothing to remember. Its state is read from the catalogue.

Status pagelive

/status

tag-platform

The detail page — the one a person opens when a card here is not green. Probed at /health/live, which probes nothing itself, so the check cannot recurse into the whole estate every time somebody refreshes.

14:00Z1 of 24 hours observednow

state: live for 8m · since 13:24Z
24 hours: not observed that long · 38.5% of 26 so far
7 days: not observed that long · 38.5% of 26 so far
30 days: not observed that long · 38.5% of 26 so far
all time: 38.5% 26 samples · 16 down · observed 24m
response: 84 ms now p50 43 ms p95 166 ms · 26 samples, 24h
changed: 1 time(s) in 24h — a service that flaps is a different problem from one that is down
last failure: 10m ago · down — [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate (_ssl.c:1016)
running: this container does not report a commit
shipped by: this repository, on a merge to develop
probe: GET /status/live · reproduce: curl -i https://develop.tag.company/status/live
expects HTTP 200
through the edge
depends on: Edge (Traefik) and TLS

HTTP 200 — liveness only — not this service's own verdict · through the edge · 84 ms

Health endpointlive

/health

tag-platform

The same data as JSON, for a monitor rather than a person: 200 while everything that is SUPPOSED to be running is running, 503 when it is not. The entries below that are held or not deployed never make it red — an endpoint that is permanently 503 is an endpoint nobody reads.

14:00Z1 of 24 hours observednow

state: live for 8m · since 13:24Z
24 hours: not observed that long · 38.5% of 26 so far
7 days: not observed that long · 38.5% of 26 so far
30 days: not observed that long · 38.5% of 26 so far
all time: 38.5% 26 samples · 16 down · observed 24m
response: 43 ms now p50 49 ms p95 133 ms · 26 samples, 24h
changed: 1 time(s) in 24h — a service that flaps is a different problem from one that is down
last failure: 10m ago · down — [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate (_ssl.c:1016)
running: this container does not report a commit
shipped by: this repository, on a merge to develop
probe: GET /health/live · reproduce: curl -i https://develop.tag.company/health/live
expects HTTP 200
through the edge
depends on: Edge (Traefik) and TLS

HTTP 200 — liveness only — not this service's own verdict · through the edge · 43 ms

Agent fleet dashboarddegraded

/agents

tag-mvp-ux/agents/tag-ui

tag-ui, deployed 2026-09-22. READ THE NEXT ROW WITH IT: what is published here is the dashboard and the four paths it serves itself, not the fleet. It calls tag-entry and tag-moderator from inside the Docker network, server-side; the agents' own endpoints (/agents/dispatch, /agents/match, /agents/fleet) answer 404 through this prefix.

14:00Z1 of 24 hours observednow

state: degraded for 8m · since 13:24Z
24 hours: not observed that long · 0.0% of 26 so far
7 days: not observed that long · 0.0% of 26 so far
30 days: not observed that long · 0.0% of 26 so far
all time: 0.0% 26 samples · 16 down, 10 degraded · observed 24m
response: 142 ms now p50 54 ms p95 122 ms · 26 samples, 24h
changed: 1 time(s) in 24h — a service that flaps is a different problem from one that is down
last failure: 0s ago · degraded — HTTP 404, expected 200
shipped by: tag-mvp-ux/agents/tag-ui, on its own merge
probe: GET /agents/health · reproduce: curl -i https://develop.tag.company/agents/health
expects HTTP 200
through the edge
depends on: Edge (Traefik) and TLStag-entrytag-moderator

HTTP 404, expected 200 · through the edge · 142 ms

Agent fleet APIinternal only

What /agents would expose if this were routed · tag-mvp-ux/agents

STILL INTERNAL ON PURPOSE, and this is the row that carries the security decision. The fleet authenticates no caller, so publishing its API would hand anyone on the internet the ability to drive it and spend its model budget. That a UI now sits at /agents does not change it, and must not be read as having changed it. Every agent is running and is reported, from inside the network, in the three Agent fleet tiers below. See ../docs/agents-exposure.md.

state: internal only
shipped by: tag-mvp-ux/agents, on its own merge
depends on: tag-entry

Never probed, so there is nothing to remember. Its state is read from the catalogue.

Truss client portalok

/client

truss-interfaces/apps/portal

SERVES ITS OWN PREFIX AND THE EDGE MUST NOT STRIP IT. `/client` is compiled into the image by Next.js basePath, so moving it is a rebuild in truss-interfaces and not a routing change here. Routed by a committed label in ../truss/compose.yaml; the file-provider router for the same prefix stays held, because two definitions of one route is undefined. See ../docs/truss-portals.md.

14:00Z1 of 24 hours observednow

state: ok for 8m · since 13:24Z
24 hours: not observed that long · 38.5% of 26 so far
7 days: not observed that long · 38.5% of 26 so far
30 days: not observed that long · 38.5% of 26 so far
all time: 38.5% 26 samples · 16 down · observed 24m
response: 166 ms now p50 44 ms p95 177 ms · 26 samples, 24h
changed: 1 time(s) in 24h — a service that flaps is a different problem from one that is down
last failure: 10m ago · down — [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate (_ssl.c:1016)
shipped by: truss-interfaces, once it is built with a basePath
probe: GET /client · reproduce: curl -i https://develop.tag.company/client
expects HTTP 200
through the edge

HTTP 200 · through the edge · 166 ms

Truss firm portalok

/firm

truss-interfaces/apps/firm

A SEPARATE IMAGE from the client portal, not the same one served twice — each app compiles its own basePath, so the firm image answers 404 at /client and the portal image answers 404 at /firm. The same prefix rule as the row above, and the same reason its router is held.

14:00Z1 of 24 hours observednow

state: ok for 8m · since 13:24Z
24 hours: not observed that long · 38.5% of 26 so far
7 days: not observed that long · 38.5% of 26 so far
30 days: not observed that long · 38.5% of 26 so far
all time: 38.5% 26 samples · 16 down · observed 24m
response: 103 ms now p50 52 ms p95 212 ms · 26 samples, 24h
changed: 1 time(s) in 24h — a service that flaps is a different problem from one that is down
last failure: 10m ago · down — [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate (_ssl.c:1016)
shipped by: truss-interfaces, once it is built with a basePath
probe: GET /firm · reproduce: curl -i https://develop.tag.company/firm
expects HTTP 200
through the edge

HTTP 200 · through the edge · 103 ms

Back-officeheld

/backoffice

tag-backoffice

Held by the captain's decision — "for tag-Gateway and /backoffice lets wait a little". Nothing technical is in the way.

state: held
shipped by: tag-backoffice, when the captain releases the hold

Never probed, so there is nothing to remember. Its state is read from the catalogue.

TAG-Gatewayheld

/gateway

tag-gateway

Held by the captain's decision, the same sentence. Reserved, not overlooked.

state: held
shipped by: tag-gateway, when the captain releases the hold

Never probed, so there is nothing to remember. Its state is read from the catalogue.

Marketing sitenot deployed

tag-website

Intended for the root. The front door answers there, so deploying this one is also a decision about what / should serve.

state: not deployed
shipped by: tag-website

Never probed, so there is nothing to remember. Its state is read from the catalogue.

Data tier — Supabase

unknown · 13ok · 1

Self-hosted Supabase, probed component by component rather than as one "Supabase" row: the failure worth showing is the day PostgREST is fine and Realtime is not, and a single row hides exactly that. Kong is checked through the edge because it is the only published door; everything behind it is checked from inside, where it actually lives.

Kong (API gateway)ok

/supabase

The only published door to the tier — /supabase

14:00Z1 of 24 hours observednow

state: ok for 8m · since 13:24Z
24 hours: not observed that long · 38.5% of 26 so far
7 days: not observed that long · 38.5% of 26 so far
30 days: not observed that long · 38.5% of 26 so far
all time: 38.5% 26 samples · 16 down · observed 24m
response: 121 ms now p50 57 ms p95 136 ms · 26 samples, 24h
changed: 1 time(s) in 24h — a service that flaps is a different problem from one that is down
last failure: 10m ago · down — [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate (_ssl.c:1016)
shipped by: Coolify's Supabase stack — pasted compose, not a repository
probe: GET /supabase/rest/v1/ · reproduce: curl -i https://develop.tag.company/supabase/rest/v1/
expects HTTP 200 or 401
through the edge
depends on: Edge (Traefik) and TLS

HTTP 401 · through the edge · 121 ms

PostgRESTunknown

/supabase/rest/v1

14:00Z1 of 24 hours observednow

state: unknown for 24m · since 13:08Z
uptime: nothing measurable yet · 26 sample(s), none of which measured up or down
last failure: none since this page started watching it
probe: http · the address is not published on this page
expects HTTP 200 or 401 or 404
depends on: Postgres

no probe target configured

GoTrue (auth)unknown

/supabase/auth/v1

14:00Z1 of 24 hours observednow

state: unknown for 24m · since 13:08Z
uptime: nothing measurable yet · 26 sample(s), none of which measured up or down
last failure: none since this page started watching it
probe: http · the address is not published on this page
expects HTTP 200
depends on: Postgres

no probe target configured

Realtimeunknown

/supabase/realtime/v1 — WebSocket

403 here is HEALTHY: Realtime answered the upgrade and refused it because the page sends no apikey, which is what it should do. What this probe exists to catch is the opposite — a plain GET returns something perfectly plausible while subscriptions are broken.

14:00Z1 of 24 hours observednow

state: unknown for 24m · since 13:08Z
uptime: nothing measurable yet · 26 sample(s), none of which measured up or down
last failure: none since this page started watching it
probe: websocket · the address is not published on this page
expects an upgrade handshake answering HTTP 101 or 403
depends on: Postgres

no probe target configured

Storageunknown

/supabase/storage/v1

14:00Z1 of 24 hours observednow

state: unknown for 24m · since 13:08Z
uptime: nothing measurable yet · 26 sample(s), none of which measured up or down
last failure: none since this page started watching it
probe: http · the address is not published on this page
expects HTTP 200
depends on: PostgresStorage backend (MinIO)

no probe target configured

Postgresunknown

Not published. Reachable inside the network only.

14:00Z1 of 24 hours observednow

state: unknown for 24m · since 13:08Z
uptime: nothing measurable yet · 26 sample(s), none of which measured up or down
last failure: none since this page started watching it
probe: tcp · the address is not published on this page
expects a TCP connection

no probe target configured

Supavisor (pooler)unknown

Connection pooler in front of Postgres

14:00Z1 of 24 hours observednow

state: unknown for 24m · since 13:08Z
uptime: nothing measurable yet · 26 sample(s), none of which measured up or down
last failure: none since this page started watching it
probe: http · the address is not published on this page
expects HTTP 200 or 204
depends on: Postgres

no probe target configured

Storage backend (MinIO)unknown

Object store behind the Storage API

14:00Z1 of 24 hours observednow

state: unknown for 24m · since 13:08Z
uptime: nothing measurable yet · 26 sample(s), none of which measured up or down
last failure: none since this page started watching it
probe: http · the address is not published on this page
expects HTTP 200

no probe target configured

postgres-metaunknown

Schema introspection for Studio

14:00Z1 of 24 hours observednow

state: unknown for 24m · since 13:08Z
uptime: nothing measurable yet · 26 sample(s), none of which measured up or down
last failure: none since this page started watching it
probe: http · the address is not published on this page
expects HTTP 200
depends on: Postgres

no probe target configured

Studiounknown

Supabase's own dashboard. Deliberately not published.

14:00Z1 of 24 hours observednow

state: unknown for 24m · since 13:08Z
uptime: nothing measurable yet · 26 sample(s), none of which measured up or down
last failure: none since this page started watching it
probe: http · the address is not published on this page
expects HTTP 200
depends on: postgres-metaKong (API gateway)

no probe target configured

Edge Functionsunknown

Deno runtime. No health route — checked as a listening port.

supabase/edge-runtime answers 500 on /_internal/health and 400 on /, so neither is a health signal. The honest check is that it is listening; say that rather than dressing a 500 up as green.

14:00Z1 of 24 hours observednow

state: unknown for 24m · since 13:08Z
uptime: nothing measurable yet · 26 sample(s), none of which measured up or down
last failure: none since this page started watching it
probe: tcp · the address is not published on this page
expects a TCP connection
depends on: Postgres

no probe target configured

Analytics (Logflare)unknown

Log sink the whole tier writes to

14:00Z1 of 24 hours observednow

state: unknown for 24m · since 13:08Z
uptime: nothing measurable yet · 26 sample(s), none of which measured up or down
last failure: none since this page started watching it
probe: http · the address is not published on this page
expects HTTP 200
depends on: Postgres

no probe target configured

Vectorunknown

Ships container logs into Logflare

14:00Z1 of 24 hours observednow

state: unknown for 24m · since 13:08Z
uptime: nothing measurable yet · 26 sample(s), none of which measured up or down
last failure: none since this page started watching it
probe: http · the address is not published on this page
expects HTTP 200
depends on: Analytics (Logflare)

no probe target configured

imgproxyunknown

Image transformation for Storage

14:00Z1 of 24 hours observednow

state: unknown for 24m · since 13:08Z
uptime: nothing measurable yet · 26 sample(s), none of which measured up or down
last failure: none since this page started watching it
probe: http · the address is not published on this page
expects HTTP 200
depends on: Storage backend (MinIO)

no probe target configured

Agent fleet — the way in

ok · 2

Everything reaching the fleet arrives through tag-entry. If this is not green, nothing below it will be doing anything, however green it looks — so read this tier first and the other two only if it is fine.

tag-entryok

Fleet entry point · :8200

14:00Z1 of 24 hours observednow

state: ok for 10m · since 13:23Z
24 hours: not observed that long · 42.3% of 26 so far
7 days: not observed that long · 42.3% of 26 so far
30 days: not observed that long · 42.3% of 26 so far
all time: 42.3% 26 samples · 15 down · observed 24m
response: 194 ms now p50 196 ms p95 4,075 ms · 26 samples, 24h
changed: 1 time(s) in 24h — a service that flaps is a different problem from one that is down
last failure: 11m ago · down — [Errno 111] Connection refused
shipped by: tag-mvp-ux/agents, on its own merge
probe: http · the address is not published on this page
expects HTTP 200
inside the network

HTTP 200 · inside the network · 194 ms

tag-plannerok

Plans the work before it is handed out · :8102

14:00Z1 of 24 hours observednow

state: ok for 10m · since 13:23Z
24 hours: not observed that long · 42.3% of 26 so far
7 days: not observed that long · 42.3% of 26 so far
30 days: not observed that long · 42.3% of 26 so far
all time: 42.3% 26 samples · 15 down · observed 24m
response: 92 ms now p50 109 ms p95 3,094 ms · 26 samples, 24h
changed: 1 time(s) in 24h — a service that flaps is a different problem from one that is down
last failure: 11m ago · down — [Errno 111] Connection refused
shipped by: tag-mvp-ux/agents, on its own merge
probe: http · the address is not published on this page
expects HTTP 200
inside the network
depends on: tag-entry

HTTP 200 · inside the network · 92 ms

Agent fleet — model-backed

ok · 3

THE THREE THAT CALL A MODEL, and the three that cost money to run. They share one credential with TrueForge — the estate's JEV_API_KEY, which is an OpenRouter key — so when classification and matching go quiet, the row to read next is OpenRouter in External dependencies, not these. That they answer at all is itself a signal: require_decision_config() runs in each one's startup hook and the process exits without the key, so a missing credential shows up here as down, not as silence.

tag-moderatorok

Decides where a mark goes · :8101 · calls a model

14:00Z1 of 24 hours observednow

state: ok for 10m · since 13:23Z
24 hours: not observed that long · 42.3% of 26 so far
7 days: not observed that long · 42.3% of 26 so far
30 days: not observed that long · 42.3% of 26 so far
all time: 42.3% 26 samples · 15 down · observed 24m
response: 86 ms now p50 94 ms p95 4,061 ms · 26 samples, 24h
changed: 1 time(s) in 24h — a service that flaps is a different problem from one that is down
last failure: 11m ago · down — [Errno 111] Connection refused
shipped by: tag-mvp-ux/agents, on its own merge
probe: http · the address is not published on this page
expects HTTP 200
inside the network
depends on: tag-entryOpenRouter (JEV_API_KEY)

HTTP 200 · inside the network · 86 ms

tag-matcherok

Matches marks to expectations · :8103 · calls a model

14:00Z1 of 24 hours observednow

state: ok for 10m · since 13:23Z
24 hours: not observed that long · 42.3% of 26 so far
7 days: not observed that long · 42.3% of 26 so far
30 days: not observed that long · 42.3% of 26 so far
all time: 42.3% 26 samples · 15 down · observed 24m
response: 79 ms now p50 105 ms p95 4,038 ms · 26 samples, 24h
changed: 1 time(s) in 24h — a service that flaps is a different problem from one that is down
last failure: 11m ago · down — [Errno 111] Connection refused
shipped by: tag-mvp-ux/agents, on its own merge
probe: http · the address is not published on this page
expects HTTP 200
inside the network
depends on: tag-entryOpenRouter (JEV_API_KEY)

HTTP 200 · inside the network · 79 ms

tag-arc-creatorok

Turns plans into arcs · :8107 · calls a model

14:00Z1 of 24 hours observednow

state: ok for 10m · since 13:23Z
24 hours: not observed that long · 42.3% of 26 so far
7 days: not observed that long · 42.3% of 26 so far
30 days: not observed that long · 42.3% of 26 so far
all time: 42.3% 26 samples · 15 down · observed 24m
response: 64 ms now p50 77 ms p95 4,051 ms · 26 samples, 24h
changed: 1 time(s) in 24h — a service that flaps is a different problem from one that is down
last failure: 11m ago · down — [Errno 111] Connection refused
shipped by: tag-mvp-ux/agents, on its own merge
probe: http · the address is not published on this page
expects HTTP 200
inside the network
depends on: tag-entryOpenRouter (JEV_API_KEY)

HTTP 200 · inside the network · 64 ms

Agent fleet — document pipeline

ok · 4not deployed · 1

Deterministic processing: a document arrives, and these four carry it from bytes to a mark with an expectation attached. They call no model, so an OpenRouter outage does not touch them — if documents stop moving while the tier above is green, the fault is here.

tag-ingestionok

Takes the document in · :8104

14:00Z1 of 24 hours observednow

state: ok for 10m · since 13:23Z
24 hours: not observed that long · 42.3% of 26 so far
7 days: not observed that long · 42.3% of 26 so far
30 days: not observed that long · 42.3% of 26 so far
all time: 42.3% 26 samples · 15 down · observed 24m
response: 55 ms now p50 94 ms p95 4,049 ms · 26 samples, 24h
changed: 1 time(s) in 24h — a service that flaps is a different problem from one that is down
last failure: 11m ago · down — [Errno 111] Connection refused
shipped by: tag-mvp-ux/agents, on its own merge
probe: http · the address is not published on this page
expects HTTP 200
inside the network
depends on: tag-entry

HTTP 200 · inside the network · 55 ms

tag-extractionok

Pulls content out of it · :8105

14:00Z1 of 24 hours observednow

state: ok for 10m · since 13:23Z
24 hours: not observed that long · 42.3% of 26 so far
7 days: not observed that long · 42.3% of 26 so far
30 days: not observed that long · 42.3% of 26 so far
all time: 42.3% 26 samples · 15 down · observed 24m
response: 79 ms now p50 80 ms p95 4,059 ms · 26 samples, 24h
changed: 1 time(s) in 24h — a service that flaps is a different problem from one that is down
last failure: 11m ago · down — [Errno 111] Connection refused
shipped by: tag-mvp-ux/agents, on its own merge
probe: http · the address is not published on this page
expects HTTP 200
inside the network
depends on: tag-entry

HTTP 200 · inside the network · 79 ms

tag-enrichmentok

Adds what the content implies · :8106

14:00Z1 of 24 hours observednow

state: ok for 10m · since 13:23Z
24 hours: not observed that long · 42.3% of 26 so far
7 days: not observed that long · 42.3% of 26 so far
30 days: not observed that long · 42.3% of 26 so far
all time: 42.3% 26 samples · 15 down · observed 24m
response: 71 ms now p50 85 ms p95 4,039 ms · 26 samples, 24h
changed: 1 time(s) in 24h — a service that flaps is a different problem from one that is down
last failure: 11m ago · down — [Errno 111] Connection refused
shipped by: tag-mvp-ux/agents, on its own merge
probe: http · the address is not published on this page
expects HTTP 200
inside the network
depends on: tag-entry

HTTP 200 · inside the network · 71 ms

tag-expectationok

Attaches the obligation it satisfies · :8108

14:00Z1 of 24 hours observednow

state: ok for 10m · since 13:23Z
24 hours: not observed that long · 42.3% of 26 so far
7 days: not observed that long · 42.3% of 26 so far
30 days: not observed that long · 42.3% of 26 so far
all time: 42.3% 26 samples · 15 down · observed 24m
response: 87 ms now p50 85 ms p95 4,047 ms · 26 samples, 24h
changed: 1 time(s) in 24h — a service that flaps is a different problem from one that is down
last failure: 11m ago · down — [Errno 111] Connection refused
shipped by: tag-mvp-ux/agents, on its own merge
probe: http · the address is not published on this page
expects HTTP 200
inside the network
depends on: tag-entry

HTTP 200 · inside the network · 87 ms

tag-anchornot deployed

The tail of the pipeline — publishes to a public network

Absent in the Coolify environment — it refuses to anchor without a bootstrapped OpenETR signing identity in a volume. Nothing here is anchored, and nothing upstream of it is affected: the pipeline runs to completion and stops one step short of publishing.

state: not deployed

Never probed, so there is nothing to remember. Its state is read from the catalogue.

Supporting services

unknown · 2not checked · 2

Things no path points at, that a published service stops working without. They are listed because "the chat is broken" is usually one of these, and an operator should not have to already know they exist.

TrueForge Postgresunknown

Holds TrueForge's sessions AND its provider credentials

Dropping this volume loses the OpenRouter provider configuration — it lives here, not in the container environment and not in this repository.

14:00Z1 of 24 hours observednow

state: unknown for 24m · since 13:08Z
uptime: nothing measurable yet · 26 sample(s), none of which measured up or down
last failure: none since this page started watching it
probe: tcp · the address is not published on this page
expects a TCP connection

no probe target configured

TrueForge Redisunknown

Queues and schedule state for the chat

14:00Z1 of 24 hours observednow

state: unknown for 24m · since 13:08Z
uptime: nothing measurable yet · 26 sample(s), none of which measured up or down
last failure: none since this page started watching it
probe: tcp · the address is not published on this page
expects a TCP connection

no probe target configured

TAG Staff databasenot checked

A `paperclip` database inside supabase-db, with its own role

NOT a second Postgres. It is a database of its own inside the existing supabase-db service, owned by a `paperclip` role that can reach nothing else — so a Paperclip migration cannot touch the product's tables, and a dump of one is not a dump of the other. Nothing on this page has a credential for it, so this page will not claim to have checked it: the Postgres row in the data tier is what says the server is up. Paperclip runs on 15.8 — established by running its migrations against supabase/postgres:15.8.1.085, not assumed from its compose, which pins 17. See ../paperclip/README.md.

state: not checked
shipped by: nothing — it is a database inside the Supabase service, created once by hand; paperclip/README.md has the three statements

Never probed, so there is nothing to remember. Its state is read from the catalogue.

TrueForge controllernot checked

Runs the schedule-dispatch loop, out of process

A worker with no listening port and no health endpoint. Nothing on the network can observe it, so this page will not pretend to: if schedules stop firing, read its container log. Reporting a guess as green is the failure this page is built to avoid.

state: not checked
shipped by: this repository, pinned to the same image as /chat
depends on: TrueForge PostgresTrueForge Redis

Never probed, so there is nothing to remember. Its state is read from the catalogue.

Platform

unknown · 1ok · 1

The edge itself and the control plane that deploys onto it. If the edge row is not green you are not reading this page, so treat it as the certificate's expiry clock — the quiet failure that takes the whole origin down on a date nobody has in their calendar.

Edge (Traefik) and TLSok

One origin, one certificate, one thing to renew

14:00Z1 of 24 hours observednow

state: ok for 8m · since 13:24Z
24 hours: not observed that long · 38.5% of 26 so far
7 days: not observed that long · 38.5% of 26 so far
30 days: not observed that long · 38.5% of 26 so far
all time: 38.5% 26 samples · 16 down · observed 24m
response: 79 ms now p50 50 ms p95 82 ms · 26 samples, 24h
changed: 1 time(s) in 24h — a service that flaps is a different problem from one that is down
last failure: 10m ago · down — certificate rejected: CERTIFICATE_VERIFY_FAILED
shipped by: Coolify's own proxy — not from this repository
probe: tls · the address is not published on this page
expects a certificate a browser accepts, more than 21 days from expiry
through the edge
depends on: Platform DNSLet's Encrypt

valid, 89 days left · through the edge · 79 ms

Coolifyunknown

Deploys and supervises everything above. Its own host.

Not on this origin, and nothing here depends on it at request time — it is down that redeploys and restarts stop being possible, not the site.

14:00Z1 of 24 hours observednow

state: unknown for 24m · since 13:08Z
uptime: nothing measurable yet · 26 sample(s), none of which measured up or down
last failure: none since this page started watching it
probe: http · the address is not published on this page
expects HTTP 200

no probe target configured

External dependencies

ok · 7

Not ours, and the reason this page is worth building. Of the three things that blocked this estate on 2026-09-21, TWO were external — Dynamic.xyz's origin allowlist and Docker Hub refusing an image pull — and neither would appear in a check that only looks at our containers. So neither is checked by reachability here: the allowlist is checked by asking Dynamic whether THIS origin is on it, and Docker Hub by taking an anonymous pull token and reading the rate limit back. Anything failing here is DEGRADED rather than down, is listed under `external` in /health, and NEVER changes that endpoint's status code: what we run and what we depend on are counted separately, because an endpoint answering 503 on somebody else's bad afternoon is one everybody learns to ignore. The allowlist row is the single exception, and says why. Each row also declares which answer is healthy — a registry's 401 and Anthropic's 401 are both correct — because "is it 200" and "is it well" are different questions.

Dynamic.xyz origin allowlistok

Authentication. Login fails silently if this origin is not listed.

This asks the real question. On 2026-09-21 every container was healthy and login was impossible because this environment's origin was not on Dynamic's list; a reachability check was green throughout. The probe sends this origin and requires Dynamic to echo it back in Access-Control-Allow-Origin — which it only does for an allowed origin. The environment id is public: it ships in the browser bundle.

14:00Z1 of 24 hours observednow

state: ok for 24m · since 13:08Z
24 hours: not observed that long · 100% of 26 so far
7 days: not observed that long · 100% of 26 so far
30 days: not observed that long · 100% of 26 so far
all time: 100% 26 samples · observed 24m
response: 165 ms now p50 174 ms p95 269 ms · 26 samples, 24h
last failure: none since this page started watching it
probe: cors · the address is not published on this page
expects Access-Control-Allow-Origin naming this origin — reachability is not the question
outbound

this origin is allowlisted · outbound · 165 ms

Docker Hub pull quotaok

Image registry — rate-limits anonymous pulls by IP

Reachability was never the problem. Coolify's Supabase template referenced minio/mc with no tag, Docker Hub answered "pull access denied", and because one failed pull aborts the whole `docker compose pull`, NOTHING started. This probe takes an anonymous pull token and reads the quota back, so the row goes amber while there is still headroom rather than on the deploy that fails.

14:00Z1 of 24 hours observednow

state: ok for 24m · since 13:08Z
24 hours: not observed that long · 100% of 26 so far
7 days: not observed that long · 100% of 26 so far
30 days: not observed that long · 100% of 26 so far
all time: 100% 26 samples · observed 24m
response: 339 ms now p50 339 ms p95 409 ms · 26 samples, 24h
last failure: none since this page started watching it
probe: registry · the address is not published on this page
expects an anonymous pull token for ratelimitpreview/test and a quota that is not spent
outbound

85 pulls left of 100/hr · outbound · 339 ms

quay.iook

Image registry — where minio/mc actually comes from

401 ON THE MANIFEST IS THIS REGISTRY WORKING, and this row said "degraded" for it. quay.io answers /v2/ with a bearer challenge and issues an anonymous pull token — a complete, healthy handshake — and then refuses minio/mc, because MinIO's community repositories are no longer anonymously readable on quay.io OR on Docker Hub. That is MinIO's access policy, not quay.io's health, and until the expected statuses below were declared this page reported it as an outage of theirs and (through the verdict) as an outage of ours. Re-establish it rather than trusting this paragraph: curl -s https://quay.io/v2/ -o /dev/null -w '%{http_code}\n' — 401 with a WWW-Authenticate header is the healthy answer. The thing this row cannot tell you is whether a redeploy of the Supabase stack can still pull minio/mc; it cannot, anonymously, and the Docker Hub row above is where that first showed up.

14:00Z1 of 24 hours observednow

state: ok for 24m · since 13:08Z
24 hours: not observed that long · 100% of 26 so far
7 days: not observed that long · 100% of 26 so far
30 days: not observed that long · 100% of 26 so far
all time: 100% 26 samples · observed 24m
response: 420 ms now p50 291 ms p95 408 ms · 26 samples, 24h
last failure: none since this page started watching it
probe: registry · the address is not published on this page
expects an anonymous pull token for minio/mc and a quota that is not spent
outbound

registry serving; minio/mc is not anonymously readable (HTTP 401, as declared) · outbound · 420 ms

OpenRouter (JEV_API_KEY)ok

Model access for tag-matcher, tag-moderator, tag-arc-creator

The credential the estate carries as JEV_API_KEY is an OpenRouter key (sk-or-v1-…), and TrueForge's provider uses the same one. Named here for what it is, because a row labelled only "Jev API" sends whoever is debugging a 401 to the wrong dashboard. Reachability only — the model list, which spends no quota.

14:00Z1 of 24 hours observednow

state: ok for 24m · since 13:08Z
24 hours: not observed that long · 100% of 26 so far
7 days: not observed that long · 100% of 26 so far
30 days: not observed that long · 100% of 26 so far
all time: 100% 26 samples · observed 24m
response: 57 ms now p50 72 ms p95 145 ms · 26 samples, 24h
last failure: none since this page started watching it
probe: http · the address is not published on this page
expects HTTP 200
outbound

HTTP 200 · outbound · 57 ms

Anthropic APIok

LLM provider for the fleet (ANTHROPIC_API_KEY)

14:00Z1 of 24 hours observednow

state: ok for 24m · since 13:08Z
24 hours: not observed that long · 100% of 26 so far
7 days: not observed that long · 100% of 26 so far
30 days: not observed that long · 100% of 26 so far
all time: 100% 26 samples · observed 24m
response: 110 ms now p50 108 ms p95 134 ms · 26 samples, 24h
last failure: none since this page started watching it
probe: http · the address is not published on this page
expects HTTP 401 or 403
outbound

HTTP 401 · outbound · 110 ms

Let's Encryptok

Certificate issuance and renewal

Issuance, not the certificate in use — that is the Edge row in the Platform tier, which counts the days left on the one being served.

14:00Z1 of 24 hours observednow

state: ok for 24m · since 13:08Z
24 hours: not observed that long · 100% of 26 so far
7 days: not observed that long · 100% of 26 so far
30 days: not observed that long · 100% of 26 so far
all time: 100% 26 samples · observed 24m
response: 208 ms now p50 204 ms p95 309 ms · 26 samples, 24h
last failure: none since this page started watching it
probe: http · the address is not published on this page
expects HTTP 200
outbound

HTTP 200 · outbound · 208 ms

Platform DNSok

Does the platform host resolve?

14:00Z1 of 24 hours observednow

state: ok for 24m · since 13:08Z
24 hours: not observed that long · 100% of 26 so far
7 days: not observed that long · 100% of 26 so far
30 days: not observed that long · 100% of 26 so far
all time: 100% 26 samples · observed 24m
response: 1 ms now p50 0 ms p95 3 ms · 26 samples, 24h
last failure: none since this page started watching it
probe: dns · the address is not published on this page
expects a name that resolves
outbound

resolves · outbound · 1 ms