Skip to content

Availability Management Policy

Purpose. Soon's customers plan and run their workforce through the platform; if it is down, their operations stall. This policy states how Soon keeps the service available and detects availability problems early.

1. Scope

The production environment of the Soon platform in AWS eu-west-1 and the services it depends on (including Netlify). Internal tools are out of scope.

2. Policy

  • Availability targets (confirmed 2026-08-13).
Target Value Meaning
Uptime 99.5% ≈3.6 hours of unplanned downtime per month
RTO (recovery time objective) 8 hours Maximum time to restore service after a major failure
RPO (recovery point objective) 24 hours Maximum data loss, aligned to daily automated snapshots

These reflect what Soon can genuinely deliver today on single-region AWS with daily snapshots. They are internal objectives; any contractual uptime commitment to a customer must be agreed individually and must not exceed them. Once point-in-time recovery is enabled and a restore has been tested, the RPO should be revisited downwards (see Backup Policy). - Redundancy. Production infrastructure uses the redundancy AWS provides. Verified 2026-08-13: the production database rds-soon-soon-prod runs Multi-AZ (automatic failover to a standby in a second availability zone), is encrypted at rest and has deletion protection enabled. Application workloads run on ECS/Fargate behind AWS-managed load balancers. - Monitoring & alerting. Availability is monitored continuously (CloudWatch; errors via Sentry). Alerts on outage or degradation must reach the on-duty engineer promptly. Routing (confirmed 2026-08-13): CloudWatch alarms and GuardDuty findings publish to the soon-security-alerts SNS topic, which delivers to security@soon.works (Slack #Security via AWS Chatbot pending). - Capacity. Resource utilisation is reviewed so capacity problems are seen before they cause outages; scaling decisions follow change management. - Recovery. Loss of data or infrastructure is recovered per the Backup Policy; availability incidents are reported and handled per the event reporting procedure. - Dependencies. Availability commitments of critical suppliers (AWS, Netlify) are considered in supplier reviews per the Supplier Relationships Security Policy.

3. Roles & responsibilities

  • Technical lead (Thomas Picauly) — owns the availability design and monitoring configuration. TODO(owner): confirm.
  • Engineers — respond to availability alerts and report incidents.

Change log

Version Date Author Comments
0.1 — — CertiKit-derived template
0.2 2026-07-18 Andrea Cardinali Rewritten lean and Soon-specific (ISMS overhaul); kept standalone because the Backup Policy (checklist pilot) covers A.8.13 only