Most database applications are chains of dependencies. A client resolves a server name, crosses a network, authenticates through an identity system, opens a connection, runs application code, requests data, and waits for storage and compute to complete the work. A failure anywhere in that chain can appear to the user as “the database is down.”
Start with the timeline, not the blame
Ask what changed and when. Was there a password rotation, server restart, DNS update, certificate renewal, firewall change, deployment, storage event, or new workload? A reliable timeline is often more useful than the first error message.
Separate connection, execution, and waiting
Can the client resolve the server? Can it reach the port? Can the same identity authenticate using another tool? Does a simple query work? Is the session waiting on a lock, disk, network call, or application transaction? Breaking the symptom into stages narrows the field quickly.
Common causes outside the database engine
- DNS records, aliases, or cached names point to the wrong location.
- Service accounts, passwords, group membership, or delegation changed.
- Firewalls, VPNs, routes, or load balancers interrupt the path.
- Storage latency or capacity makes database work appear slow.
- The application opens too many connections or leaves transactions active.
- Server time, certificates, or operating-system services are inconsistent.
The right owner is the person following the evidence
Complex incidents improve when someone can move comfortably across boundaries and keep testing the next dependency. The goal is not to make every issue a database issue. It is to restore the business process and leave the team with a diagnosis it can understand.
Stuck between vendors?
Describe the symptoms, what changed, and what each team has already checked.