Module 8 Lesson 4: Deployment Health

A "Green" pipeline doesn't mean the site is working. The pipeline only knows if the Upload worked. We need Deployment Health to know if the Running App is actually serving users.

1. What is Deployment Health?

After the deployment job finishes, GitLab can "Poll" your website's URL. It checks:

HTTP Status: Does it give a 200 OK?
Latency: Does it take 10 seconds to load? (This is a "Partial Failure").

2. Integrated Monitoring (Prometheus)

GitLab can connect to Prometheus (a popular monitoring tool).

It will show a small graph next to your Environments page.
The Benefit: You can see exactly how the "Deployment Moment" affected the server's RAM and CPU usage. If RAM spikes to 99% right after the change, you have a memory leak!

3. Post-Deployment Alerts

You can configure GitLab to send an "Alert" to your engineering lead if:

Error rates increase by 5% in the 10 minutes following a deployment.
The "Success" page is timing out.

4. The "Stop" Signal

If you find a critical health failure, you immediately hit the Rollback button (Review Module 6). This is why having health data inside GitLab is so powerful—you don't have to switch between 3 different tabs to know that a deployment went wrong.

Exercise: The Health Check

Go to Operate -> Environments.
Click on your production environment.
Find the "Monitoring" icon (it looks like a small heartbeat).
If you had a bug that caused the site to load in 30 seconds instead of 1 second, how would this dashboard help you find it?
Research: What is the "GitLab Alert Management" feature? How does it differ from a standard Slack notification?

Summary

Pipeline monitoring is "Pre-deployment." Environment monitoring is "Post-deployment." You need both to have a truly resilient stack. By watching your application's vitals after every change, you ensure that your "Ships" don't just leave the harbor, but actually arrive at their destination.

Next Lesson: Locking the door: Automated Alerts for Security Findings.