The exact error, and how to fix it.

A query ran longer than statement_timeout allows, so PostgreSQL killed it. The timeout is doing its job. The real question is why the query got slow.

Parallel query workers exchange data through POSIX shared memory in /dev/shm, and the container gave them only 64MB. Grow /dev/shm or shrink the per gather memory.

In Redis Cluster, multi-key commands need every key in the same hash slot. Use hash tags to co-locate related keys, or avoid cross-slot multi-key ops.

Redis hit its maxclients limit and every new connection is turned away. Here is how to kill the stale clients, find who leaked them, and raise the ceiling safely.

MySQL has hit max_connections and is rejecting clients. Get in on the reserved slot, kill the leak, then size the pool right.

MySQL matched your connection to a user@host account and the credentials failed for that pair. The host half of the account is the part everyone forgets to check.

Writes are failing because something ran out of room: the disk, a tablespace, or a temporary table in memory. Find which one before you delete anything.

A transaction waited past innodb_lock_wait_timeout for a row lock another transaction is holding. Find the blocker, then keep transactions short.

One statement tried to lock more rows than MySQL had room to track. Batch the write, grow the InnoDB buffer pool, or convert MyISAM tables to InnoDB.

Two transactions locked rows in opposite orders and neither could proceed, so InnoDB killed one. The deadlock report names the exact queries and locks involved.

One database account has hit its personal connection cap. The server may be fine; that user cannot open another session until existing ones close or the limit is raised.

The connection to MySQL was dropped mid-query. Usually a timeout, an oversized packet, or a server that restarted. Diagnose before you retry.

The client was mid query when the connection vanished. A crashed server, a fired timeout, an oversized packet, and a network drop all produce this same message. The server error log tells them apart.

The data volume is full and PostgreSQL cannot write. Free space carefully, because deleting the wrong file corrupts the cluster.

Two transactions touched the same rows under a strict isolation level, and PostgreSQL aborted one to protect consistency. The fix is a retry loop, not a config change.

Two transactions each hold a lock the other needs. PostgreSQL killed one to break the cycle. Here is how to stop the cycle forming.

Error 28 is the operating system's ENOSPC: a disk is full. The culprit is the data directory or the tmpdir where big sorts and temp tables spill.

Every ordinary connection slot is taken. Your app cannot connect at all, and the usual cause is a connection leak or missing pooler, not a database failure.

The server you reached has no role by that name. Either the role was never created on this cluster, or you are connecting to a different cluster than you think.

PostgreSQL has hit max_connections and is refusing every new connection. Restore service, then find the leak.

A hot standby cancelled your query because replaying WAL would have removed rows the query still needed. Choose between replica lag, primary bloat, or moving the query.

A single statement or row exceeded the packet size limit, so MySQL refused it. The limit exists on both server and client, and both must be raised for the fix to stick.

Redis restarted and is reading its dataset back into memory, refusing commands until it finishes. The bigger question is why Redis restarted and how long the load will take.

The last background save failed, so Redis stopped accepting writes on purpose. Find why BGSAVE fails (disk, memory, or permissions) and writes come back.

Redis hit its maxmemory limit and the noeviction policy is rejecting every write. Here is how to free memory now and stop it recurring.

The shared lock table is full. Some transaction is taking far more object locks than the server was sized for, and partitioned tables are the usual suspect.

Your application is writing to a Redis replica, which refuses by design. After a failover this means clients are still pointed at the old master. Fix the routing, not the replica.

The encrypted connection to PostgreSQL died mid conversation. The client only sees EOF; the real story is in the server log, the kernel log, or the network path between them.

The kernel is refusing to create new processes. You have hit a process, thread, or PID limit. Here is how to get a shell back and find the cause.

A dev server or watcher asked the kernel to watch more files than inotify allows, so it fails with a misleading ENOSPC. Raising the watch limit fixes it.

A required shared library is missing or not on the dynamic loader's path, so the binary cannot start at all. Find the library, install it, and refresh the cache.

The kernel refused to fork a new process, so even simple commands fail. It is memory or PID exhaustion, and you may need an existing shell to dig your way out.

The volume is full, or you are out of inodes. Find the space before you start deleting, because deleting the wrong thing makes it worse.

The kernel ran out of memory and killed a process to survive. Find what consumed the RAM before it happens again.

The kernel killed the process for touching memory it does not own. The crash is in the core dump, and reading its backtrace beats guessing every time.

A process ran out of file descriptors, so every new connection or file open fails. Raising the limit buys time; finding what holds thousands of descriptors is the fix.

Writes are failing because the filesystem is mounted read-only, and on a production box that usually means the kernel demoted it after a disk error. Check dmesg before remounting.

The storage account rejected an authenticated request, most often because firewall or private endpoint network rules block the caller, not because the credentials are wrong.

Azure is throttling your requests at some layer: ARM, a service limit, or Cosmos DB request units. The Retry-After header tells you when to come back; the layer tells you what to fix.

You exceeded a Google Cloud quota or per resource rate limit. The fix is three steps: back off and retry, find the exact quota in the console, then raise it or spread the load.

The App Service front end forwarded the request to your app and got nothing valid back. The app crashed, hung past the platform timeout, or never came up after a restart or swap.

The load balancer is up but every target in the group failed health checks, so there is nowhere to send traffic. Fix one target and service returns; the health check reason tells you what to fix.

Something between the caller and the workload refused or failed the request. The first question is whose 503 it is: Google's API, your load balancer, or your own backend.

Some layer of AWS policy evaluation denied the call. The error names the principal and action; the fix is finding which of the five policy layers said no.

ECS cannot pull your container image. Almost always the image reference, the network path to the registry, or the execution role. Here is how to tell which.

Connection refused means nothing was listening where the app knocked. With Cloud SQL that is almost always the Auth Proxy not running, IAM blocking it, or the network path to the instance. Here is the checklist.

AWS hid the real denial reason inside an encoded blob. Decode it with sts decode-authorization-message and the JSON names the exact statement, action, and resource that said no.

Azure SQL says the database is temporarily unavailable. Often a transient failover, sometimes a real resource cap. Retry correctly, then find out which.

Temporary credentials from STS, SSO, or an assumed role hit their expiry. The quick fix is to re-login or re-assume; the real fix is letting the SDK refresh credentials instead of caching a token.

Google rejected the call because the project ran into a quota. It is either a per-minute rate quota or a hard allocation quota, and the fix is different for each. Here is how to tell them apart and clear both.

AWS temporarily has no physical capacity for that instance type in that Availability Zone. This is not your quota; the fix is another AZ, an equivalent type, mixed instances, or a capacity reservation.

AWS does not recognize the access key ID in the request. The cause is a deleted, disabled, or wrong-partition key, or stale credentials, and the fix starts with confirming who you actually are.

AWS rejected a policy because its JSON is structurally invalid: a bad ARN, missing Version, wrong Principal, or a condition typo. Validate it with the policy tools and the message points to the field.

AWS is blocking the call because something is not opted in: a disabled region, a missing Marketplace or service subscription, or an account that is not fully activated. Enable the right one and retry.

The API authenticated the caller and then refused it. The trap is that the caller is often not the identity you think it is. Here is how to identify the real principal, the missing permission, and the layer that blocked it.

DynamoDB is throttling you. Sometimes it is real capacity, but very often it is a hot partition. Here is how to tell and fix both.

Your machine's clock is off from AWS by more than 15 minutes, so SigV4 signature validation fails. Sync the host clock with NTP and the calls start working again.

S3 is throttling you, usually because too many requests hit the same key prefix at once. Retries with backoff stabilize it, key design fixes it.

Your app's outbound connections are failing intermittently because it ran out of SNAT ports. The cure is connection reuse plus a real outbound path like NAT Gateway, not a restart.

A stack whose very first create failed lands in ROLLBACK_COMPLETE, which is a terminal state you cannot update. The fix is to correct the template, delete the stack, and recreate it.

Your function hit its configured timeout and Lambda killed it mid execution. The default is only 3 seconds; the fix is finding what it was waiting on, not just raising the limit.

Your RDS instance has no free storage, so writes are failing or the instance sits in STORAGE_FULL. Adding allocated storage is the fix; knowing what filled it prevents the rerun.

Cloud Run started your container but nothing began listening on $PORT before the startup deadline. Usually the app binds the wrong port or address, or crashes during boot.

AWS is rate-limiting your API calls. The fix is correct exponential backoff plus jitter, and reducing the call rate at the source.

An update failed, then the rollback failed too. The recovery is continue-update-rollback, skipping only the truly stuck resources, then reconciling those by hand before deploying again.

Your backend block differs from what Terraform last initialized. You must re-init, but the wrong flag can strand your state. Here is when to reconfigure and when to migrate.

Two or more resources reference each other, so Terraform cannot order them. Here is how to see the loop with terraform graph and break it, including the security group classic.

The remote backend lock is held by another run. Usually a crashed apply left it behind. Here is how to confirm nothing is live and release the lock without corrupting state.

A resource has prevent_destroy = true and your plan would destroy or replace it. This guard usually protects databases. Here is how to find why, and whether to override it.

Your count comes from a value Terraform will not know until apply, such as the length of a computed list. count must be known at plan time. Here is how to base it on known inputs.

Your for_each keys come from a value Terraform will not know until apply, such as an ID from another resource. Keys must be known at plan time. Here is how to fix the map.

The provider returned a value during apply that differed from the plan. This is almost always a provider bug, not your HCL. Here is how to work around it and report it.

Your saved plan file no longer matches current state, so Terraform will not apply it. Common in CI where plan and apply are separate stages. Here is how to regenerate cleanly.

An Nginx worker ran out of connection slots and started dropping requests. Raising worker_connections is step one, but the OS file descriptor limit has to rise with it.

A request body was bigger than Nginx allows. The default client_max_body_size is 1 MB, and the limit can be set at several layers, so find the one that is actually rejecting you.

Something between your client and the origin decided you sent too many requests. The fix is finding which limiter fired, honoring Retry-After, and smoothing the bursts that trip it.

The client hung up before your backend finished answering. A 499 is never sent to anyone; it is Nginx telling you that responses are slower than callers are willing to wait.

Nginx could not get a valid response from your backend. The 502 page is generic, but the Nginx error log names the exact failure. Start there.

Your client received a certificate chain ending in a CA it does not trust, almost always a corporate TLS proxy or a private CA. The fix is trusting that CA explicitly, never turning verification off.

Silence, not rejection. Something between you and the target is dropping packets, or the host is gone. Refused and timed out point at different culprits.

The browser and the server failed to complete a TLS handshake at all. Something on port 443 is not speaking valid, modern TLS, and openssl s_client will tell you what.

Cloudflare reached out to your origin and got a broken or missing response. The branding on the error page tells you whose side failed, and it is usually the origin.

The hostname did not resolve to an IP address. It is a name problem, not a connection problem. Start with the hostname printed in the error, exactly as printed.

The browser made the request, got the response, and refused to hand it to your JavaScript because the server never said the origin was allowed. Fix is server side, always.

DNS answered that the domain name does not exist at all. Either the record is genuinely missing, the wrong nameservers are answering, or a stale negative answer is cached.

The remote end sent a TCP RST instead of closing cleanly. Somebody crashed, timed out, or reused a connection the other side had already abandoned.

An Nginx worker hit its open file descriptor limit and could not create a new upstream socket. Raise worker_rlimit_nofile and the systemd LimitNOFILE, not just worker_connections.

The resolver tried to answer and failed. Usually broken authoritative servers or a DNSSEC validation failure. The +cd flag tells you which in one query.

The host could not get an answer from any DNS resolver at all. This is not a missing record; it is a broken path between the machine and its resolver.

Your app closed the connection before answering. Look for a crash, an OOM kill, a timeout shorter than the request, or a keepalive connection the proxy reused after the app already closed it.

Your backend answered, but its response headers were larger than the Nginx proxy buffer. Users see a 502, and the fix is either bigger buffers or smaller headers.

The scheduler cannot fit your pod on any node because CPU requests exceed what is free. Fix the requests or add capacity.

The pod cannot schedule because its PersistentVolumeClaim never bound to a volume. Fix the StorageClass or provisioner and the PVC binds.

A container keeps crashing and Kubernetes keeps restarting it with growing backoff. CrashLoopBackOff is a symptom. Here is how to find the real crash.

The kubelet cannot build the container config because a referenced ConfigMap, Secret, or key is missing. The pod events name exactly what it cannot find.

The kubelet just failed to pull your container image and the pod cannot start. The Failed event under kubectl describe pod holds the exact registry error.

The namespace ResourceQuota has no room left for the CPU your new pods request, so the API server refuses to create them. Deploys and scale-ups silently stall.

Kubernetes tried to pull the container image, failed, and is now backing off between retries. The pod events name the exact pull failure. Start there.

The kubelet probed your health endpoint and got a 503, so the pod was pulled out of load balancing. The question is why your own app says it is not ready.

The container exceeded its memory limit and the kernel killed it. Exit code 137 means SIGKILL from an OOM. Here is how to right-size it.

The kubelet hit its disk pressure threshold and killed pods to reclaim space. Find what filled the node's disk before the evictions cascade to other nodes.

Nginx gave up waiting on the backend and returned 504. The timeout is the symptom. The fix is almost always upstream, not Nginx.

Entra ID cannot find an app registration matching the client ID you sent, in the tenant you sent it to. Usually a wrong client ID or wrong tenant.

The token endpoint rejected the credential you exchanged: a used or expired authorization code, a dead refresh token, a mismatched redirect_uri, or clock skew. Identify which grant type failed before touching anything.

The token's signature does not match what the verifying key computes, so the verifier and the signer disagree about the key. Decode the header, identify the signer, and compare keys.

The client cannot build a trust chain to a known root. Almost always a missing intermediate cert or an outdated CA bundle. Do not just disable verification.

The token is past its exp claim, so verification fails. Expiry is by design. The fix is correct refresh handling, not longer-lived tokens.

A TLS certificate in the chain is expired or not yet valid, or the system clock is wrong. Confirm the real cause before you regenerate anything.

The client cannot trace the server certificate to a CA it trusts. Either the server is not sending its full chain, or the client is missing the root. Do not disable verification.