Reliability
How Kinetry stays up, how deploys are kept safe, and what happened the one time they weren't.
An external probe checks the service on a recurring schedule (in practice roughly hourly): a liveness endpoint that verifies the application can reach its database, and a page request that verifies the middleware layer is the expected deployed version (every response carries a deploy-version header). A failed probe alerts the founder directly. Application errors are captured in real time by Sentry, configured without session replay or personal-data capture.
Continuous integration runs typecheck, unit tests, database-integration tests, and a production build on every push — plus a schema-drift gate that replays every committed database migration into a clean database and fails if the result differs from the declared schema in either direction. Risky changes ship as canary deploys: small, individually-verifiable steps with a pre-staged revert, so recovery from a bad deploy is measured in seconds, not hours.
The database (Neon PostgreSQL) provides point-in-time recovery, and Kinetry's readiness program includes a documented quarterly restore-drill procedure — recovery is treated as something to verify on a schedule, not assume.
What happened: minutes after a routine deploy, requests began failing with a platform middleware error (MIDDLEWARE_INVOCATION_FAILED). The site was intermittently unavailable to visitors during the incident window.
Response: a pre-staged revert to the previous deployment was triggered immediately; service was restored roughly 80 seconds after the decision to revert. No data was lost or at risk at any point — the failure was in the request-routing layer, not the database.
Root cause: a corrupted build asset on that one deployment of the hosting platform's edge layer. The application code was unchanged and innocent: the identical code was later redeployed as a controlled canary and ran cleanly, confirming the asset — not the change — was at fault.
What changed: every response now carries a deploy-version header so a bad deployment is identifiable within seconds; risky changes ship as canary micro-steps with pre-staged reverts; and this page exists, so the next incident is written up in public too.
Related: Security & data protection · Subprocessors