Your primary database fails over at 3am and writes start erroring. What are your first moves?

Confirm the new primary is actually promoted and accepting writes, then check whether applications reconnected. Stale connection pools and cached DNS are the usual reason errors continue after a healthy failover. Verify replication lag and whether any committed writes were lost against your RPO. Restore write traffic, rule out split brain by making sure the old primary is fenced, then take the postmortem question of why failover was not transparent.

Step one is confirming reality: connect to the new primary directly and check it is out of recovery and accepting writes. If the database is healthy and applications are still erroring, the problem is on our side, and in my experience that is where it usually is. Connection pools hold sockets to an address that no longer serves writes, or the JVM cached the DNS entry forever, so the fix is a rolling restart or a pool with proper validation. We had one where a driver honored a 30 second TTL but the pool never revalidated idle connections, so recovery took twenty minutes longer than it should have. Then I check replication lag at the moment of promotion to see if we lost committed writes, because that changes who I need to tell. I also want confirmation the old primary is fenced and cannot accept a write if it comes back. Once writes are flowing, the postmortem question is why this was not automatic.