What to Watch After Every Deployment: Five Signals That Tell You If Your New Version Is Healthy
You just deployed a new version. The pipeline says green. The team is watching the dashboard. But is the application actually working well for users?
Without concrete signals, you are guessing. Guessing might work when only you use the app. But when other people depend on it, you need data. You need to know, within minutes, whether the new version is healthy or broken.
Here are five basic signals that every team should monitor after deployment. Start with one or two, then add the rest over time.
Availability: Can Users Reach the Application?
The most basic question after deployment is simple: is the application accessible? If the server is down, the application crashed on startup, or the port is not open, availability drops to zero.
Teams typically monitor this with a health check endpoint. This is a special URL that the application exposes just to answer "am I alive?" Monitoring tools hit this endpoint regularly. If it stops responding, something is wrong.
Availability is usually measured as a percentage: 99%, 99.9%, or 99.99% of expected uptime. The higher the target, the less tolerance you have for interruptions. A 99% target means you can afford about 7 hours of downtime per month. A 99.99% target means about 4 minutes per month.
To check availability immediately after deployment, run a simple curl command against your health endpoint:
curl -f http://localhost:8080/health && echo "OK" || echo "FAIL"
The -f flag makes curl return a non-zero exit code if the HTTP response is an error (4xx or 5xx). A zero exit means the endpoint is reachable and healthy. You can use this in a deployment script to automatically decide whether to proceed or roll back.
After deployment, check availability first. If the application is not reachable, nothing else matters.
Error Rate: How Many Requests Are Failing?
An application can be alive but broken. Every request that comes in might fail. Error rate measures how many requests end with an error code, like HTTP 500 or a timeout.
Before deployment, you should know your baseline error rate. Maybe it is 0.5% of all requests. After deployment, if that number jumps to 5%, something in the new version is causing failures.
Error rate spikes are often the first alarm that something went wrong. They are easy to spot and usually indicate a real problem. A sudden increase in errors should trigger an immediate investigation, not a "let's wait and see."
Latency: How Fast Does the Application Respond?
Users do not like waiting. If a page that used to load in one second now takes five seconds, users will leave. Latency measures how quickly the application responds to requests.
Latency can increase for many reasons. The new code might be slower. The database connection pool might be full. The server might be overwhelmed by traffic. Whatever the cause, higher latency degrades the user experience directly.
You need to know the normal latency range before deployment. After deployment, compare the numbers. If the average response time doubles, something changed. Even small increases in latency can indicate problems that will get worse under higher load.
Saturation: How Full Are Your Resources?
Every system has limits. CPU, memory, disk space, database connections, thread pools, network bandwidth—all of them have a ceiling. Saturation measures how close you are to those limits.
After deployment, watch the resource usage. If CPU usage went from 40% to 90%, the new version is consuming more resources. That might be fine if you have spare capacity. But if traffic increases later, that 90% will become 100%, and the application will slow down or crash.
Saturation also helps with capacity planning. If a server is consistently at 80% usage, you probably need to add another server before the next traffic spike. Monitoring saturation after deployment tells you whether the new version changed the resource profile of your application.
Logs: What Actually Happened Inside?
Not everything can be captured as a number. When error rate spikes, you need to know why. That is where logs come in. Logs are records of events that the application writes while running.
Good logs have levels: info for normal operations, warning for unusual but not critical events, error for failures. They also have context: timestamp, request ID, function name, and relevant data. Without context, logs are just noise.
When something goes wrong after deployment, logs are the first place to look. Did a specific exception appear? Did a particular input cause a crash? Is the database not responding? Logs tell the story that numbers alone cannot.
Start Small, Be Consistent
You do not need to monitor all five signals from day one. Start with availability and error rate. Those two will catch most problems. Add latency when you need to understand performance. Add saturation when you start doing capacity planning. Add logs when you need to debug deeper issues.
The important thing is consistency. Every deployment should be measured the same way. Use the same health check endpoint. Collect error rates from the same source. Measure latency with the same tools. Only then can you compare versions honestly: is the new version better or worse than the old one?
These five signals give you data instead of feelings. Data tells you whether to proceed, roll back, or investigate further.
Quick Checklist for Post-Deployment Monitoring
- Health check endpoint is responding
- Error rate is not significantly higher than baseline
- Average latency is within normal range
- CPU, memory, and disk usage are not near capacity
- Logs show no unexpected errors or exceptions
What Comes Next
These signals tell you whether the application is healthy, but they do not tell you whether the new feature actually works as expected. A version can have perfect availability, low error rate, fast latency, and still deliver the wrong result. That is where verification comes in.
But before you get there, make sure these five signals are in place. Without them, you are flying blind. With them, you have a foundation for knowing what happens after every deployment.