Service explained in plain language
Application Gateway sits in an application's request path and evaluates backend health through configured probes. An unhealthy backend means the probe contract did not succeed; the application may be unavailable, unreachable or simply responding differently from what that contract expects. Each possibility requires different evidence.
Setup prerequisites and starting sequence
- Define frontend listeners, certificates, backend configuration and the application's expected hostname and protocol. Map the actual traffic path before choosing settings.
- Configure a lightweight probe and the network permissions needed to reach it. Review hostname and certificate validation for the chosen backend connection.
- Establish diagnostic access, deployment ownership and a controlled test of healthy and unhealthy behavior before production use.
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
After a backend replacement, local application tests work but gateway traffic fails. The new server expects a hostname or TLS configuration different from the configured backend probe. Increasing every timeout cannot correct an incompatible request contract.
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 |
|---|---|---|
| Probe reports an unexpected status | Compare probe path, host and accepted response with the backend behavior | A valid page outside the probe path does not satisfy the check. |
| Backend cannot be reached | Review relevant network controls, DNS and backend listener | Reachability failure precedes application status evaluation. |
| TLS-related health evidence appears | Inspect the selected hostname and certificate trust expectations | Disabling verification changes security rather than demonstrating the intended healthy path. |
Begin with status and scoped diagnostics. Sanitize shared evidence and escalate any check beyond your approved access.
Corrective action and change boundary
Apply the narrowly supported backend, probe or application correction with the responsible owner. Preserve the previous configuration for reversal. Do not create an always-successful probe or weaken TLS validation merely to make a health indicator green while ordinary requests still fail.
Verification: what proves recovery
Confirm backend health and exercise the public application operation through the gateway. Check the expected hostname, secure connection and error behavior during the observation period. Verify an approved failure scenario in non-production so operators understand what the probe is intended to detect.
Monitoring, SLI, SLO and SLA
Monitor backend health, gateway errors and user-transaction success as separate signals. An internal SLO should measure the product's valid requests and response budget; a healthy-probe count is supporting platform evidence rather than the whole customer commitment.
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 over a selected 30-day window, with probe correctness tested independently.
SOP and escalation handover
The gateway owner maintains routing; the application owner defines its readiness and hostname contract. Retain sanitized health reason, backend reference, release change and verification. Escalate before changing a shared gateway listener or probe affecting several applications.
SOP means standard operating procedure. Retain owner, evidence, approved change, reversal conditions and acceptance. Escalate with sanitized errors and resource identifiers.
Beginner glossary
Backend: the application destination behind the gateway. Probe: a diagnostic request. Hostname validation: checking that a secure endpoint matches its intended name.
Clouvenix can help scope setup, management and operational support around a documented environment and agreed acceptance criteria.
Technical reference
Official Azure 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.