The deploy is done. The pipeline passed, the health check returned 200, the release is in production. The natural tendency is to close the tab and move on to the next task. But "returned 200" and "configured the way it should be" are different statements, and the gap between them is where many incidents start.
A service can be available and, at the same time, have a certificate about to expire, be missing critical security headers, or serve stale public data. Uptime answers "is it responding?". The post-deploy checklist answers "is everything correct from the perspective of someone accessing it from outside?".
Availability and latency
The first item is the most obvious, but it is worth detailing. Checking availability is not just making a GET request and expecting 200. It means verifying:
- Does the main endpoint respond with the expected status?
- Is latency reasonable for the region of the person accessing it? A deploy that changed dependencies can double response time without changing the status code.
- Is the returned content what you expect? A 200 with an empty body or a fallback page is not a success.
For APIs, it is worth making a request that exercises the critical path — not just the health check. Health checks often bypass the actual application and respond directly from the load balancer or sidecar.
SSL/TLS certificate
The second item is the one that usually gets skipped. A deploy can, directly or indirectly, affect the certificate:
- Is the certificate delivered on port 443 the correct one for that hostname? Infrastructure changes (swapping a load balancer, adjusting a reverse proxy) can cause the server to start serving an old or wrong certificate again.
- How many days remain until expiry? If the deploy happened in an environment that just renewed the certificate, it is worth confirming the new one is being served.
- Is the chain complete? Missing intermediates cause errors in strict clients even when the leaf certificate is valid.
A quick check with curl -vvI https://yourdomain.com shows the delivered certificate and the chain. In environments with multiple hostnames or conditional routes, it is worth testing each one.
Security headers
Security headers are server or reverse proxy configuration, and infrastructure changes can alter them without warning. The main ones to check:
- Strict-Transport-Security (HSTS). Tells the browser to always use HTTPS on that domain. Without it, the first visit may fall back to HTTP and be vulnerable to downgrade.
- X-Content-Type-Options: nosniff. Prevents the browser from guessing the MIME type of a response, reducing the risk of misinterpreting content.
- Content-Security-Policy (CSP). Defines where the page can load resources from. A deploy that changes the origin of assets (CDN, S3 bucket) can break the page if the CSP is not updated accordingly.
- X-Frame-Options or frame-ancestors in CSP. Controls whether the page can be loaded in iframes. Relevant for preventing clickjacking.
None of these headers are on by default. They need to be explicitly set in the configuration. If the deploy changed how the server is served — for example, switching from nginx to a managed load balancer — the headers may have been lost along the way.
Domain and related public data
The last item is the most neglected. A public domain carries more information than the page content:
- Are DNS records pointing to the expected destinations? An IP or CNAME change may have been part of the deploy, and it is worth confirming it has propagated.
- Are email security records (SPF, DKIM, DMARC) consistent? If the deploy involved changing the email provider, these records need to be aligned.
- Have public domain data (such as information exposed in response headers or metadata) changed?
This kind of verification rarely makes it into the standard checklist, but it is exactly what an external visitor — or a monitoring tool — sees.
Why do this after every deploy
A post-deploy checklist does not replace integration tests, staging, or canary releases. It covers a different space: the moment when the code is already in production, but nobody has yet looked at the service the way an external visitor would. That is the window where configuration problems stay active for hours or days, until someone notices through the visible symptom.
Turning these checks into routine — or automation — reduces the time between the deploy and the detection of a problem that did not show up in tests.
Next step
Take the four items — availability, certificate, headers, and public data — and turn them into a script or a pipeline step that runs automatically after every deploy. What is not automatic becomes a forgotten item. If automation is not feasible right now, at least document the checklist and keep it visible for whoever does the final review.
External monitoring tools like cymesh can run these checks continuously, not just at deploy time, and keep a history of what changed and when. The principle, however, is the same: available is not the same as reviewed.