Last reviewed 2 September 2026. Written from what runs today; where a control is not yet on, it says so.
This page is the incident response plan, published rather than filed, so that the person reading it is the person it protects. It covers how a problem is noticed, how it is classified, what we do first, when and how you hear from us, what happens afterwards, and the backup and restore facts a continuity reviewer asks for.
1. How an incident is detected
- Independent uptime monitoring. app.feerasta.ai, feerasta.ai and relate.feerasta.ai are checked every five minutes by an external monitor with a public status page. You do not have to ask whether something is down.
- A deploy that verifies itself. Every deploy restarts the service, runs a read-only smoke suite and a Postgres dashboard render, and rolls back to the previous commit automatically if either fails, reporting whether the rollback fixed it. A bad release is caught before a customer is.
- The watchdog. A health check with 150 assertions covers cron health, the mail-ingest watermark, scheduler uniqueness and skill freshness, and writes a verdict (OK, WARN, FAIL) to the health page. Its email alert is a separate switch that is off today (see section 8), so its findings are read on the health page and at each deploy rather than paged to a phone.
- Production auditing of the agents. Every eligible customer exchange is scored, not a sample; a risky exchange becomes a finding for a person to triage, and a confirmed failure switches a live channel off and becomes a permanent probe.
- Backup verification. The nightly dump is checked for size, schema and data before it counts, and a failed dump exits loudly instead of leaving a zero-byte file that looks like a backup. That exact failure happened once, on 18 August 2026, and is why the check exists.
- Reports from you. hello@feerasta.ai for anything that looks wrong; security@feerasta.ai for a vulnerability.
2. How it is classified
One person, the founder, classifies within the first-response window on the security page: four hours during support hours when something is down or a customer-facing agent is answering wrongly, one business day otherwise. Three classes:
AvailabilityThe platform, the website or Relate is unreachable or a core route errors. Detected by the monitor or the deploy gate. Fix or roll back first, explain second.
Agent behaviourA customer-facing agent answers wrongly, fails a safety standard or sends something it should not. The channel is switched off before anything else is done; the audit trail says what was sent to whom.
DataPersonal data accessed, disclosed, altered or lost outside the customer's instructions, including at a subprocessor. Starts the 72-hour clock in section 4 and the evidence preservation in section 5.
Not an incidentA carrier delay, a provider outage that the product degrades around (drafts queue, nothing sends), a single refused message. Logged, not escalated, and written up on the status page if customers noticed.
3. What we do first
- Stop the harm. Roll back the deploy, switch the affected channel off, revoke the key, or set the platform-wide kill switch for outbound mail or SMS. Every outbound channel already starts off, and an environment kill switch beats any tenant setting, so containment is a flag, not a code change.
- Preserve the record. The audit ledger has no update or delete route and is kept three years; the last fourteen nightly dumps are on the server and encrypted offsite. Nothing is purged during an incident.
- Establish scope from the ledger. Which tenants, which channels, which messages, which approvals, from the tenant-attributed audit rows rather than from memory.
- Fix, test, deploy through the gate. The fix ships the way every change ships: tests on both database backends, the smoke suite, automatic rollback. A security finding gets a test that failed before the fix and passes after, so it cannot come back quietly.
4. When and how you hear from us
- Platform-wide incidents. Every workspace owner gets an email from hello@feerasta.ai saying what is affected, what we know and when the next update comes. The status page carries the open incident at the top while it lasts and keeps it afterwards with what happened and what changed.
- Personal data breaches. The affected customer is notified without undue delay and in any event within 72 hours of us becoming aware, as the data processing agreement commits, with what we know at that point and updates as we learn more, so that you can meet your own notification duties.
- Incidents affecting one workspace. Its owner is emailed directly. Nothing about one customer's incident is published.
- Subprocessor incidents. Treated as ours for notification purposes; the provider's own notice is forwarded when we have it.
- Who writes. The founder. There is one escalation step and it is him.
5. After the incident
Every incident that reached a customer gets a written review: timeline, root cause, what detected it and what should have, what changed in code or process, and the test that now guards it. The review is added to the source-of-truth file the business runs on, dated, so it is not reintroduced; the customer-facing version goes on the status page. We already publish our own failures this way: the verification page discloses that a component of our system failed silently for six weeks, and the security review lists every defect found with its fix commit.
6. Reporting a problem
Something looks down or wrong
Email hello@feerasta.ai. Something that has stopped a business working is handled outside support hours too. Support hours are Monday to Friday, 9am to 6pm Eastern.
A security vulnerability
Email security@feerasta.ai. Expectations are at /.well-known/security.txt: we acknowledge within two business days, keep you informed, and credit you if you wish. There is no paid bounty. We would rather hear it from you than from someone else.
7. Backups and restore, exactly
FrequencyNightly. A full dump of the production PostgreSQL database plus an archive of the file attachments it references.
VerificationEach dump must pass a size floor, contain the schema and contain data before it is kept; otherwise the run fails loudly and the previous good copy stands.
RetentionFourteen days of nightly copies on the server. Offsite copies are pushed nightly to the encrypted target.
EncryptionCopies leaving the server are encrypted before they leave (an rclone crypt remote), so the offsite provider, Google Drive, cannot read them. On the server itself the disk is not full-disk encrypted today.
Offsite targetGoogle Drive, listed on the subprocessors page for exactly this purpose. One server in Germany runs the platform; the offsite copy is the second location.
Restore drillA scripted drill restores the newest dump into a throwaway database, checks a structural floor of at least forty tables with plausible row counts, and destroys the container on every exit path. First run 1 August 2026; rerun after any change to the backup script.
Recovery pointBecause backups are nightly, the most that can be lost after a total server failure is one day. We do not publish a recovery-time figure we have not yet measured under load.
Restore safetyThe restore script refuses to write to the live database without an explicit force flag, matched on host and database so a pooled and a direct endpoint both count as live.
8. What is not yet on, said plainly
- Watchdog email alerts. The alert switch (
ALERT_SEND) is off, so a failing internal check is seen on the health page and at deploy time rather than paged. External uptime alerts are live. Turning it on is a decision for the founder and will be recorded here when it is made.
- A second server or region. None. Recovery from server loss is a restore from the nightly backup onto a rebuilt host.
- Full-disk encryption on the application server. Not enabled today; secrets and backups are encrypted, the disk is not.
- A published recovery-time objective and an uptime percentage. Neither, until ninety days of measured history exist.
- An external audit of this plan. None. The plan is public so that you can audit it yourself.
Last reviewed 2 September 2026. Related: the questionnaire, answered, security, status, trust, DPA. Questions: hello@feerasta.ai.