Reliability, status and incidents

Where Anpheros runs, what is monitored, daily backups and point-in-time recovery, how incidents are communicated, data export and deletion, and what is not in place yet (no SLA, no public status page).

What Anpheros does today to keep the API available and your data recoverable, how you hear about problems, and what is not in place yet. Anpheros Platform is in private beta; this page states the current setup, not targets presented as guarantees.

Hosting

Monitoring

• Uptime checks call the platform's health endpoint from three regions; when it stops answering, the team is alerted by email.
• Alerts also fire on server errors above 5 %, slow responses (p95 above 2 seconds for 10 minutes), a high share of 4xx answers, database pool exhaustion, failures to write the audit log, a broken audit chain, reuse of an OAuth refresh token, and webhook endpoints that were disabled after repeated failures.
• There is no public status page yet. The checks above are internal. A status page will be published only when it can show real measurements from these checks, not a hand-written "all systems operational".

Backups and recovery

• Database: automated backup every day at 02:00 UTC, 7 kept, plus point-in-time recovery for the last 7 days; deletion protection is on.
• Documents: object versioning and a 7-day soft delete on the storage bucket, encrypted with a customer-managed key.
• Audit log: an append-only copy outside the database, verified daily for gaps and tampering.
• Restore drill: on 20 September 2026 the production database was cloned to a point three minutes in the past; the clone was usable after about 10 minutes and its record counts matched the source. A full restore also needs a redeploy, about 5 more minutes.

When something goes wrong

1. The alert reaches the team; the affected requests are traced by their request id (every response carries an Anpheros-Request-Id header; quote it when you write to us).
2. A leaked credential is revoked first; if data integrity is in doubt, writes are stopped and the database is restored to a point before the event.
3. Organisations whose data was affected are told directly, within the timeline of their data processing agreement; for a personal-data breach, within 72 hours of becoming aware of it, as GDPR requires.
4. A post-mortem follows within 5 working days.

Changes to the API, including security-related tightening, are announced in the changelog.

Your data: export, retention and deletion

• Export: records are standard HL7 FHIR R4; Patient/$everything returns a patient's whole record as a FHIR bundle, and $summary an International Patient Summary. Nothing is in a proprietary format.
• Deletion: an organisation can delete the resources it wrote (FHIR DELETE, or DELETE on /v1 resources); earlier versions stay in the resource history. What happens to production data when a plan ends is set out in the pricing terms.
• Audit: every read and write is logged and visible to the patient. Audit rows are currently kept indefinitely; a retention period per record type is a pending legal decision.

Not in place yet

• automatic failover across zones, and a contractual SLA;
• a public status page with measured uptime;
• formal certifications (for example ISO 27001 or SOC 2): none is claimed.

These are listed so that you can plan around them. Questions: [email protected].

Related

• Security, privacy and data residency
• Limits and rate limits
• Versioning and changelog
• Pricing