What happens
when something breaks.

Every API route and server action in apps/web is wrapped with Sentry capture. Errors fire to the founder's inbox in near-real-time with PII scrubbed at the SDK level. Release tags pinned to VERCEL_GIT_COMMIT_SHA so an alert maps to the exact commit.

Each scheduled job (founding-rescreen, OCDD cadence, deadline nudges, news monitor, nurture sender, trial expiry, weekly digest) is monitored at the Vercel platform level. A failed run posts to Sentry with the cron path and the failure body so the founder sees a missed compliance job within minutes.

Supabase Auth surfaces rate-limit triggers, brute-force attempts, and unusual sign-in patterns in the project dashboard. Reviewed weekly by default, immediately if any single account shows a spike.

security@caltury.com.au is monitored by the founder. A vulnerability disclosure file is published at /.well-known/security.txt per RFC 9116 so researchers know where to send a report.

Unauthorised access to customer records, a successful tenant-isolation breach, a leaked credential or backup, or the application being entirely unreachable for the practitioner customer. Treated as crisis-level.

Partial outage, a slow path that blocks the workflow, or a regression in a sensitive function (sanctions screening returning stale results, SMR drafting failing, audit-log writes silently dropping). Customer-affecting but not data-exposing.

A non-blocking bug, a minor inaccuracy, a visual regression, a slow page that does not block the user. Recorded and fixed but not escalated as a crisis.

Affected customers are emailed within 24 hours of P0 detection regardless of contract size. Notification covers: what happened, what data was involved, what we are doing, what the customer should do, and where to follow updates. Sent from a named founder address, not a generic noreply.

P1 incidents that materially affect a customer workflow (sanctions screening down, SMR drafting unavailable, audit-log writes failing) are emailed to affected orgs within 72 hours with the current state, the workaround if any, and the expected fix window.

P2 items roll up into the next monthly changelog email and the public /changelog feed. No separate per-incident email because the noise-to-signal ratio would harm trust.

Once a P0 is judged a suspected eligible data breach, the formal assessment under s.26WH commences within 24 hours of detection. The assessment captures: nature of the breach, types of personal information involved, individuals affected, risk of serious harm, and remedial actions.

If the assessment concludes likely risk of serious harm and remediation is not possible, the OAIC is notified via the eligible-data-breach form and the affected individuals are notified directly. Notification covers the elements required by s.26WK: kind of breach, type of information, recommended response steps, Caltury contact for follow-up.

Every assessment is logged in the audit trail with the outcome and reasoning, even when the breach does not cross the OAIC threshold. The record is retained for the same 7-year window as the AML/CTF records on which Caltury operates.

The public status page is updated within 1 hour of any P0 or P1 detection. Updates follow the convention investigating then identified then monitoring then resolved so polling monitors that consume the page see a familiar status ladder.

The same incident data is exposed as JSON at /api/status so a third-party monitor, RSS reader, or future external dashboard can mirror our public state without scraping HTML.

The /status page is a founder-maintained record, not third-party uptime monitoring. The distinction is repeated on the page itself so a visitor is never misled about what they are reading.

P0 and P1 incidents produce a written postmortem covering: timeline, root cause, contributing factors, customer impact, what worked in response, what did not, and a list of preventative actions with owners and dates. Sent to affected customers; the founder is the named owner of each action.

Where the postmortem would help the broader Tranche 2 community (a Supabase platform incident, a sub-processor outage, a regression that hit multiple orgs), a public version is published to /changelog with customer identifiers removed.

Each preventative action is logged with a due date. A weekly founder review walks the open list. Outstanding actions older than 30 days surface in the next monthly changelog as a transparency commitment to customers who saw the original incident.