AWS Outage Checklist: What to Check When Your Server Is Down

When an AWS-hosted service is down, start by confirming the user-visible failure, then move inward through DNS, the load balancer, EC2 health, the operating system, and the application. Collect evidence before restarting anything. A rushed reboot can erase useful logs, extend the incident, or restart a service that was never the cause.

If your team cannot safely isolate an active outage, use a defined escalation path or request an emergency AWS server review. Never share root passwords or secret access keys.

First five minutes: stabilize the response

Before changing infrastructure:

1. Record when the problem started, who reported it, and which URLs or functions fail.
2. Assign one incident lead and one communication owner.
3. Pause deployments, scheduled maintenance, and unrelated changes.
4. Check whether the failure affects every user, one region, one network, or one application path.
5. Capture screenshots, error codes, request IDs, alarms, and recent change records.

Test from more than one network or monitoring location. A local DNS cache, firewall, or ISP route can make a healthy service appear globally unavailable.

AWS outage diagnostic path

Check	Evidence to inspect	What a failure suggests
DNS and TLS	DNS answer, alias target, certificate dates, health-check state	Incorrect record, expired certificate, propagation, or unhealthy failover target
Load balancer	Listener rules, target health, HTTP status, target response time	Bad routing, failed health check, unavailable targets, or application errors
EC2 status	System, instance, and attached EBS status checks	AWS host issue, guest OS/network issue, or storage I/O impairment
Host resources	CPU, memory, disk space, inode use, network, process state	Resource exhaustion, kernel issue, stopped service, or full filesystem
Application	Service logs, deployment history, dependency errors	Bad release, configuration error, database failure, or external dependency

Follow the path in order. If DNS resolves correctly and the load balancer answers, repeatedly editing Route 53 records adds risk without addressing the failing layer.

1. Check DNS, the certificate, and the public endpoint

Confirm that the hostname returns the expected record and points to the intended CloudFront distribution, load balancer, or public address. Check for recent hosted-zone changes and verify that the correct domain is being tested.

If the public path is unclear, compare the current routes, gateways and security boundaries with the AWS VPC design and troubleshooting guide.

Then test the TLS handshake and certificate validity. An expired or mismatched certificate is different from an application timeout. If Route 53 health checks or DNS failover are configured, inspect their state, remembering that a check proves only its configured endpoint, protocol, path, and response criteria.

2. Check the load balancer and target health

For an Application or Network Load Balancer, confirm:

• The load balancer is active and its listeners still exist.
• Listener rules forward to the expected target group.
• Security groups and network ACLs allow the required path.
• Registered targets are healthy in every intended Availability Zone.
• The health-check port, path, protocol, timeout, and success codes match the application.

If every target is unhealthy, test the health-check path directly. A deployment that changed /health authentication, redirects, port bindings, or response codes can remove otherwise running targets from service.

3. Read all three EC2 status checks

The EC2 console separates system, instance, and attached EBS status checks:

• A failed system check points toward the AWS host, power, or underlying network. For an EBS-backed instance, a stop and start can move it to new hardware, but it also changes the public IPv4 address unless an Elastic IP or stable front door is used.
• A failed instance check points toward the guest operating system or its network configuration. Common causes include exhausted memory, a damaged filesystem, an incompatible kernel, or incorrect startup configuration.
• A failed attached EBS check indicates that one or more attached volumes cannot reliably complete I/O.

Do not stop an instance until you understand whether it uses instance-store data; stopping it can destroy ephemeral data. Record its identity, volumes, Auto Scaling membership, and status first.

4. Check saturation before restarting

An instance can pass status checks while the application is unusable. Review CloudWatch and operating-system evidence for:

• CPU saturation or credit exhaustion on burstable instances
• Memory pressure, swapping, or an out-of-memory kill
• A full filesystem or exhausted inodes
• EBS latency, throughput, or IOPS constraints
• Overloaded connection pools or worker queues
• A stopped, crash-looping, or deadlocked process

CloudWatch does not collect guest memory and filesystem utilization by default; those require an agent. A structured metrics, logs, and traces strategy is faster than guessing from CPU alone.

5. Review the application and the most recent change

Check application and system logs for the first error—not only the secondary errors that followed. Compare the incident start time with:

• Application deployments
• Environment-variable or secret changes
• Database migrations
• Security-group, route-table, DNS, or certificate changes
• Instance replacement or scaling events
• Operating-system patches and reboots
• Third-party API or identity-provider incidents

If a release caused the outage, prefer its documented rollback over improvised server edits. Preserve logs so the team can learn why validation missed the problem.

6. Check databases and external dependencies

A healthy web process may still fail because it cannot reach its database, cache, queue, object store, or external service. Check dependency health, errors, credentials, quotas, and reachability.

For RDS, inspect instance events, connections, storage, CPU, memory-related metrics, failover activity, and whether the application uses the correct endpoint. Resilience choices are explained further in RDS Multi-AZ vs read replicas.

Restore service with the smallest safe action

Choose the action that addresses the evidence:

• Roll back a known bad deployment.
• Restore a changed configuration.
• Restart only the failed process when the host is healthy.
• Add capacity when saturation is proven and the architecture supports it.
• Replace an unhealthy instance through Auto Scaling when instances are designed to be disposable.
• Fail over only when the standby, data state, routing, and decision authority have been verified.
• Restore data only after identifying the required recovery point and protecting current evidence.

Make one controlled change, record it, verify the user journey, and decide whether to continue or roll back.

After recovery

Confirm more than a green homepage. Test login, writes, background jobs, integrations, and critical transactions. Monitor error rate, latency, saturation, and queues long enough to catch a recurrence.

Within the post-incident review, document the timeline, impact, root cause, contributing conditions, detection gap, and corrective owners. Improve alarms and the runbook. Review AWS backup and restore practices if recovery depended on data restoration, and use the server health checklist to identify operational controls that were missing before the outage.

Verify with AWS

• EC2 system, instance, and attached EBS status checks
• Troubleshoot an unreachable EC2 instance
• Troubleshoot Linux instances with failed status checks
• How Route 53 checks resource health

The practical takeaway

The fastest reliable recovery comes from a known diagnostic order: confirm impact, preserve evidence, test the public path, isolate the failing layer, and make the smallest reversible change. After service returns, turn what you learned into monitoring, automation, and a runbook so the next incident is shorter.