Service explained in plain language
An Application Load Balancer distributes requests to registered application targets. Health checks help it assess those targets using a configured request. An unhealthy result describes that check's outcome, not a complete diagnosis of the application. A page can work on localhost while failing the load balancer's port, path or response expectations.
Setup prerequisites and starting sequence
- Define listener behavior, certificate ownership and the target group's protocol, port and registration type for the application. Keep the public entry point distinct from management access.
- Configure a lightweight health endpoint with documented success behavior. Review traffic permissions between load balancer and target.
- Set probe timing around measured startup and failure behavior, then configure application logs and target-health monitoring. Record who approves a probe change.
Start in non-production with the approved account/subscription, region and owner. Follow the linked service instructions for exact console/API options; provisioned resources may incur charges.
Example operational issue
A release changes the application's health path, but the target group continues probing the old URL. Every new target fails the configured check. Increasing the grace period alone will not repair a path that can never return the expected result.
This is an illustrative operational example. Capture the exact error and time before making changes.
Troubleshooting: evidence before changes
| Observation | First check | Why it matters |
|---|---|---|
| Target health reports an unexpected response | Compare the configured health path and matcher with the application route | A valid web server can still fail the specific probe contract. |
| The check cannot reach the target | Inspect listener port, target registration and allowed network path | Local success does not demonstrate connectivity from the load balancer. |
| Targets fail only during startup | Compare startup measurements with probe timing and application events | A startup budget needs evidence, not an indefinitely relaxed health policy. |
Begin with status and scoped diagnostics. Sanitize shared evidence and escalate any check beyond your approved access.
Corrective action and change boundary
Coordinate the health contract between deployment configuration and application code. Correct a demonstrated path, matcher or reachability mismatch through a small reviewed change. Preserve a known-good release and probe configuration. Avoid returning unconditional health success when the application cannot serve its required workload; that hides the signal used to route customer traffic.
Verification: what proves recovery
Observe the target becoming healthy, then exercise the public user operation through the load balancer. Test a controlled unhealthy condition outside production to confirm that the probe detects its intended failure. Review application errors during a rolling replacement rather than only after all targets settle.
Monitoring, SLI, SLO and SLA
Track healthy capacity, request errors and user-transaction latency. An example SLO might measure successful customer requests over a defined monthly window; a target-health percentage alone should not be presented as the entire service availability measurement.
SLI means the measured result; SLO means an agreed internal target. SLA means a contractual commitment with its own scope and remedy. The training targets here are examples, not vendor commitments; verify current service terms before promising an SLA.
A training target could be 99.9% successful valid application requests, with a separate latency objective evaluated over 30 days.
SOP and escalation handover
The application owner defines readiness; the platform owner maintains listener and target configuration. Incident notes should include target-health reason, request evidence, release identifier and the rollback trigger. Escalate before removing every unhealthy target or changing routing broadly.
SOP means standard operating procedure. Retain owner, evidence, approved change, reversal conditions and acceptance. Escalate with sanitized errors and resource identifiers.
Beginner glossary
Listener: the load balancer entry configuration. Target group: registered destinations. Matcher: the response condition accepted by a health check.
Clouvenix can help scope setup, management and operational support around a documented environment and agreed acceptance criteria.
Technical reference
Official AWS service guidance. Validate resource-specific prerequisites and supported behavior against the deployed version. This walkthrough defines an investigation and operating contract; it does not authorize changes to someone else's environment.