Database performance degraded due to running low on system memory and utilising more swap memory. This resulted in severely degraded response times on mission control and rider APIs.
The instance struggled to recover by itself due to the volume of client connections and queries building as a result of the performance drop. The database was restarted manually with a failover to the standby instance, in order to reset connections and memory pool.

Timeline (in BST):
17:34 Monitoring flagged API outages as a result of timeouts.
18:11 Database is restarted and API response times return to acceptable levels.