Every incident, disclosed here.

The ledger

1. Health check failed for 10 minutes

   2026-08-29 · resolved 2026-08-29

   trooth.co's health check reported the site unhealthy from 17:42 to 17:52 UTC. Which of its checks failed was not recorded, and the logs from that day are no longer kept, so we cannot say whether any customer request failed. Signed-in pages that depend on the failing part may have returned errors during those minutes.

   • 2026-08-29 17:42 UTC: the health monitor first saw an unhealthy answer.
   • 2026-08-29 17:52 UTC: healthy again, without a change by Trooth.
   • 2026-10-08: entered here, late, after a review of the monitoring record against this ledger.

2. Sign-up and five other forms refused submissions

   2026-08-27 · resolved 2026-08-27

   Forms protected against bots (sign-up, password reset, feedback, document requests, requests for a network reading, and subscriptions) refused every submission because the production bot-protection secret was missing. A change that afternoon made a missing secret refuse requests instead of letting them through. Before that change, the same missing secret meant bot protection was silently off on those forms. That was a weakness, not a known attack.

   • 2026-08-27 about 15:27 UTC: a release made a missing bot-protection secret refuse submissions. The production secret was missing, so the forms began refusing.
   • 2026-08-27 16:02 UTC: the health monitor reported bot protection unhealthy.
   • 2026-08-27 about 16:43 UTC: the real secret was set in production and the site redeployed; the provider accepted it and the forms worked again.
   • 2026-10-08: entered here, late, after a review of the monitoring record against this ledger.

3. Database-level tenant isolation was not in force

   2026-08-25 · resolved 2026-08-26

   Every workspace's data. The database role serving requests could bypass row-level security, the database's own rule that each workspace sees only its rows, and before August 13 requests ran as the tables' owner, which bypasses it too. The application's own checks, which scope every request to the signed-in workspace, applied throughout: an audit of all 109 server routes on August 25 found none that lets a caller name another workspace's data. We know of no access to one workspace's data by another.

   • 2026-08-25: found while testing tenant isolation against a role that cannot bypass it.
   • 2026-08-26 01:00 UTC: production's health check began reporting the request-serving role as able to bypass row-level security.
   • 2026-08-26 04:54 UTC: production moved to a new role created with SQL that cannot bypass row-level security; the health check has passed since 04:59 UTC.
   • 2026-10-08: entered here, late, after a review of the monitoring record against this ledger.

How to report

Report security issues through the vulnerability disclosure program and factual errors through the correction path.