Postmortem
Database service interruption in the AWS UAE region
Incident details
- Date: August 13, 2026
- Severity: High
- Duration: Approximately 90 minutes
- Affected system: Primary database and dependent Sakneen services
- Related work: Multi-cloud infrastructure transition
Summary
At approximately 4:00 PM Cairo time on August 13, 2026, Sakneen became unavailable after the primary database hosted in the AWS UAE region was disrupted. The interruption lasted approximately 90 minutes.
Rather than continue waiting for the regional service to recover, the team moved the database workload to another cloud server and restored it using the latest usable backup, taken at 11:00 AM that day. Service returned at approximately 5:30 PM. The team then resynchronized external providers and reviewed the result before closing the active incident.
Impact
- Sakneen experienced a full service interruption for approximately 90 minutes, from 4:00 PM to 5:30 PM Cairo time.
- Recovery used the 11:00 AM database backup.
- The source incident report says the team resynchronized external providers and reviewed the restored data. It does not quantify how many records required reconciliation or independently establish a zero-data-loss result.
Timeline
- 11:00 AM: The latest usable database backup was captured.
- 4:00 PM: Service became unavailable after disruption to the AWS UAE region affected the primary database.
- Approximately 5:30 PM: The team restored the database on another cloud server using the 11:00 AM backup and returned the service to operation.
- After 5:30 PM: The team resynchronized external providers and reviewed the restored data.
- 1:00 AM on August 14: The source report scheduled a maintenance window to continue the infrastructure transition. Completion of that maintenance is not confirmed in this record.
Root cause
The incident report attributes the interruption to infrastructure disruption in the AWS UAE region, where Sakneen's primary database was hosted. The report does not identify a Sakneen application or code change as the trigger.
Contributing factors
- The primary database depended on a single cloud provider and region.
- Automatic failover to a verified secondary database was not available.
- Recovery required a manual migration to another server.
- The latest usable backup was taken five hours before the incident began.
Resolution and recovery
The team restored the database on another cloud server from the 11:00 AM backup. After the service returned, the team resynchronized external providers and reviewed the restored data before closing the incident.
Corrective actions
The source report lists the following planned changes:
- Accelerate the migration of the primary infrastructure from AWS to Google Cloud.
- Run the primary database in Google Cloud's Belgium region.
- Maintain a redundant database in AWS's USA region.
- Add automatic failover between the two cloud environments.
- Replace hourly snapshots with live-stream backups to reduce recovery time and the amount of data exposed between restore points.
These items remain planned until deployment and failover evidence confirms that they are operating in production.