What to Check After a Deployment Depends on What You Just Deployed

You just pushed a new version to production. The pipeline is green. The deployment finished without errors. Now what?

Most teams stare at a dashboard and hope nothing breaks. But the signals that matter depend entirely on what you deployed. Checking the same metrics for an application, a database, and an infrastructure change will leave you blind to the real problems. Each type of deployment has its own failure modes, and you need to watch the right signals for each.

Applications: Watch How Requests Are Handled

When you deploy a new version of an application, the most important thing to know is whether it is handling user requests properly. Two metrics give you that answer faster than anything else: error rate and latency.

Error rate tells you how many requests are failing. If error rate spikes right after a deployment, something is wrong. It could be a bug in the new code, a configuration mismatch, or an incompatibility with the production environment. Whatever the cause, users are hitting failures, and you need to know immediately.

Latency tells you how long the application takes to respond to requests. A sudden increase in latency means the new version is slower. It might be consuming more resources, hitting a bottleneck, or making inefficient calls to downstream services. Users may not see errors, but they will feel the slowness, and that is just as damaging.

Throughput is another useful signal, especially for applications that serve many users. Throughput measures how many requests the application can handle per unit of time. If throughput drops while the number of users stays the same, the new version is less efficient. Something in the code is slowing things down, even if error rate and latency look normal.

These three signals are the first things to check after an application deployment. They reflect what users actually experience. Do not rely on whether the process is still running or the container is up. Those tell you the application is alive, but they do not tell you if it is working correctly.

The following flowchart summarizes which metrics to check first based on what you deployed:

flowchart TD Start([Deployment Done]) --> Type{Deployment Type?} Type -->|Application| App[Check App Metrics] Type -->|Database| DB[Check Database Metrics] Type -->|Infrastructure| Infra[Check Infra Metrics] App --> App1[Error Rate] App --> App2[Latency] App --> App3[Throughput] DB --> DB1[Replication Lag] DB --> DB2[Query Performance] DB --> DB3[Connection Count] DB --> DB4[Transaction Log Size] Infra --> Infra1[Node Health] Infra --> Infra2[CPU & Memory] Infra --> Infra3[Disk Space] Infra --> Infra4[Network Latency]

Databases: Check Replication, Queries, and Connections

Databases do not serve requests directly like applications do. They provide data for applications. So the signals you need to watch are different.

Replication status is critical. Most production databases use replicas for reading data. If replication falls behind or breaks after a deployment, applications might read stale or inconsistent data. This is especially dangerous after schema changes or data migrations. A few seconds of replication lag might be acceptable, but minutes of lag means something is wrong.

Query performance is the next thing to monitor. After a deployment that changes the schema, adds indexes, or modifies how the application writes data, some queries might suddenly become slow. Watch for queries that take longer than usual or queries that start timing out. A single slow query can drag down the entire application.

Connection count matters too. Databases have a limited number of connections. If a deployment causes connections to pile up or hang, the database can run out of available connections. New requests will fail, and the application will appear broken even though the database itself is healthy.

Transaction log size is a less obvious but important signal. Databases write logs for every change. If a deployment changes how the application writes data, the log might grow faster than usual. Without proper cleanup, the log can fill up the disk and bring the database to a halt. Database teams usually have a safe threshold for log size. If it exceeds that threshold, action is needed.

Infrastructure: Start With Node Health

Infrastructure deployments include changes to servers, containers, networks, or cloud resources. The first signal to check is node health. Is the server or container still alive? Is CPU and memory usage within normal ranges? Is the disk filling up?

Healthy infrastructure is a prerequisite for applications and databases to run correctly. If a node keeps restarting or runs out of resources, everything running on top of it will suffer. Node health is the baseline. If that is broken, nothing else matters.

Network signals are also important, especially after changes to firewall rules, load balancers, or service meshes. Watch for increased latency between nodes, packet loss, or dropped connections. These problems often do not show up in application metrics directly, but they cause mysterious failures that are hard to debug.

Signals Are Connected, But Start With One

Application, database, and infrastructure signals do not exist in isolation. A slow application might be caused by a slow database. A slow database might be caused by an infrastructure node running out of memory. To get the full picture, you need to read signals from all three layers together.

But when you need to make a quick decision after a deployment, each team usually has one primary signal to watch. Application teams watch error rate and latency. Database teams watch replication and query performance. Infrastructure teams watch node health. Start there. If something looks wrong, dig into the other layers to find the root cause.

Practical Checklist for Post-Deployment Verification

  • For application deployments: check error rate, latency, and throughput within the first five minutes.
  • For database deployments: check replication lag, slow queries, connection count, and transaction log size.
  • For infrastructure deployments: check node health, CPU and memory usage, disk space, and network latency.
  • If one signal looks abnormal, check the related signals in the other layers to find the real cause.

The Takeaway

Do not use the same dashboard for every deployment. The signals that matter depend on what you just changed. Applications need request-level metrics. Databases need data-layer metrics. Infrastructure needs resource and network metrics. Know which signals to watch for each type of deployment, and you will catch problems before your users do.