Sampling every component since 2026-09-16: recording for 49 days.
Components
Every bar is one UTC day of recorded samples. The last 90 days. Recording started 2026-09-16, so the earlier days were never sampled and are shown as gaps. A day that was never
sampled is a gap, not a clean day. A day at 99.9% or better is green, and each
bar's title carries its exact uptime.
MCP endpoint
Operational
POST /mcp answers a tools/list over Streamable HTTP, signed in as the probe.
2026-08-0699.85% over 49 sampled daystoday
Verification engine
Operational
The upstream Plumbline Worker that decides every control.
2026-08-0699.98% over 49 sampled daystoday
Document extraction
Operational
A model key is configured, so documents can be transcribed.
2026-08-06100% over 49 sampled daystoday
Platform
Operational
GET /api/health on the Plumbline Platform, the signed-in workspace application at PLATFORM_URL.
2026-08-0699.99% over 35 sampled daystoday
Platform database
Operational
Postgres answers SELECT 1 through the Platform's own connection pool within 2 seconds.
2026-08-0699.99% over 35 sampled daystoday
Platform workspaces
Operational
The workspaces table holds at least one row, read through the Platform's own connection pool.
2026-08-0699.99% over 35 sampled daystoday
Platform agent
Operational
The chat transcript table answers a read and the agent's model replies to a call made with the agent's API key; the probe makes that call at most once every 5 minutes and reuses the result in between.
2026-08-0696.99% over 35 sampled daystoday
Response time
How long each probe took over the last 24 hours, one bar per hour: the solid bar is
p50 and the pale one p95. Only successful probes count, so a failed probe appears in
the uptime bars above and never as a fast response here.
MCP endpoint
p50 122 ms · p95 366 ms
24 hours agoscaled to 447 msnow
Verification engine
p50 99 ms · p95 517 ms
24 hours agoscaled to 739 msnow
Document extraction
p50 2 ms · p95 4 ms
24 hours agoscaled to 5 msnow
Platform
p50 92 ms · p95 131 ms
24 hours agoscaled to 152 msnow
Platform database
p50 100 ms · p95 1871 ms
24 hours agoscaled to 2383 msnow
Platform workspaces
p50 100 ms · p95 1871 ms
24 hours agoscaled to 2383 msnow
Platform agent
p50 100 ms · p95 1871 ms
24 hours agoscaled to 2383 msnow
Incidents
An incident opens when a component fails several samples in a row and closes when it
answers again. Start, end, and duration come from the samples. Any update below was
written by a human and is shown exactly as typed.
Platform agent — error
started 2026-10-22 01:49:07 UTCresolved 2026-10-23 01:53:04 UTC1.0 days
On October 21, Railway, our hosting provider, disclosed a security incident (QH8L8B3E) that led to this outage. An attacker read Railway customers' environment variables, which hold credentials, and Railway paused all builds and deploys.
We treated every credential stored on Railway as exposed, our database credentials among them, and revoked them between 01:19 and 01:45 UTC on October 22. To protect user data, we removed public network access to our production and development databases at 01:19 UTC, so only our services on Railway's private network reach them. We revoked and replaced the Clerk sign-in keys that control user accounts.
The Platform agent and document extraction have been unavailable since 01:49 UTC because their AI model key was revoked and Railway's build pause blocked a replacement.
Railway restored builds for all plans by 22:49 UTC on October 22. We are now redeploying our services with new credentials; this incident closes when the Platform agent check passes. We will also rotate the database password and internal tokens.
Questions: [email protected]
MCP endpoint — timeout
started 2026-09-30 15:40:27 UTCresolved 2026-09-30 15:43:18 UTC3 minutes
No update has been written for this incident.
MCP endpoint — timeout
started 2026-09-30 07:43:15 UTCresolved 2026-09-30 07:47:05 UTC4 minutes
No update has been written for this incident.
MCP endpoint — error
started 2026-09-30 07:35:05 UTCresolved 2026-09-30 07:41:05 UTC6 minutes
No update has been written for this incident.
MCP endpoint — error
started 2026-09-16 04:35:56 UTCresolved 2026-09-16 04:46:09 UTC10 minutes
This is a monitoring defect, not a service outage. The MCP endpoint served every request normally throughout. The status sampler probed the server over loopback with a Host header naming the public origin, and fetch() drops a Host header silently, so each probe was refused by the allowed-Host check. The probe now calls the public origin directly. Fix in flight.
This page holds counts and timings only: no evidence, no run ids, no client
identifiers, no addresses. Plumbline is advisory. A human makes every funding
decision.