Container Apps: Stopped Receiving Requests — Investigation and Assistance Needed

Configure an explicit liveness probe that tests whether the application can still process work—not merely whether its port is open—so Azure Container Apps can detect and restart a replica that becomes unresponsive.

Configure automatic recovery

A liveness probe determines whether the application remains responsive; readiness controls whether the replica receives traffic, while startup protects slow initialization. HTTP probes succeed only for status codes from 200 through 399.^1^

1. Implement lightweight endpoints:
   • /live: Detect a deadlock or unrecoverable internal state. Avoid making it depend on every downstream service, or a dependency outage could restart all replicas.
   • /ready: Return failure when this replica cannot safely receive traffic.
   • /startup: Return success only after initialization.
2. In the portal, open Container App → Configure → Container → Health Probes and configure the correct path and application port.
3. Start with the Microsoft reliability recommendations below, then tune them to the application’s normal latency and startup duration:^2^

probes:
  - type: Liveness
    httpGet:
      path: /live
      port: 8080
    initialDelaySeconds: 10
    periodSeconds: 10
    timeoutSeconds: 5
    failureThreshold: 3
  - type: Readiness
    httpGet:
      path: /ready
      port: 8080
    initialDelaySeconds: 5
    periodSeconds: 1
    timeoutSeconds: 1
    failureThreshold: 60

A default TCP liveness probe can establish that the process is listening without proving that the request-processing path is healthy. An explicit HTTP liveness endpoint is therefore important for detecting an application hang. Container Apps supports one probe of each type per container; exec and gRPC probes aren't supported.^1^

Determine what happened to the original replica

The 43-minute application-log gap alone cannot distinguish among:

• no requests reaching the replica;
• an application thread or event-loop hang;
• stopped stdout/stderr emission;
• an unhealthy or restarted replica;
• an ingress or environment event.

Since the basic application, system logs, and infrastructure metrics have already been reviewed, correlate these additional replica-level signals for the exact incident window:

1. Run historical detectors
   Open Container App → Diagnose and solve problems:
   • Availability and Performance → Health Probe Failures
   • Container App Down
   • Container Exit Events
   • Container Environment Events
   Health Probe Failures can be filtered by revision, time, probe type, and failure type. Environment detectors expose infrastructure events that might have affected the workload.^3^ ^4^
2. Correlate by replica identity
   System logs identify replicas with ReplicaName/ReplicaName_s; HTTP ingress logs also contain ReplicaName. Console logs use ContainerGroupName/ContainerGroupName_s. HTTP logs must be enabled through diagnostic settings on the Container Apps environment.^5^
3. Chart the incident by replica and revision
   Examine:
   • Requests
   • Replicas
   • RestartCount
   • UsageNanoCores
   • WorkingSetBytes
   • RxBytes and TxBytes
   • ResiliencyRequestTimeouts
   These metrics support replica or revision dimensions where applicable.^6^

Interpret the result as follows:

• Requests recorded, but no application output or responses: likely application-side blocking or logging failure.
• No HTTP records at all: investigate ingress or upstream routing.
• Probe failures followed by restart-count growth: the platform detected an unhealthy replica and attempted recovery.
• No probe failures and no restart: the configured probe probably continued succeeding or did not test the hung execution path.
• Replica disappeared or changed without an app-side exit: preserve the environment-event evidence for Azure Support.

Reduce single-replica impact

For an ingress-exposed production workload, use multiple always-ready replicas. Microsoft recommends at least three replicas for improved availability; traffic can continue through other healthy replicas while one is removed or restarted.^2^

Also create alerts under Container App → Monitoring → Alerts for request failures, response latency, replica count, restart count, probe failures, and missing application heartbeats. Alerts can be split by Revision or Replica.^7^

Escalate the retrospective incident

If the detectors and replica correlation still show no cause, open an Azure support request for Azure Container Apps → App down or reporting errors. Include:

• incident start/end in UTC;
• subscription, environment, app, revision, and affected replica names;
• client request IDs and observed HTTP status/timeout behavior;
• detector exports for probe, exit, and environment events;
• replica-dimensioned request, restart, CPU, memory, and network charts;
• timestamp and method of the manual restart;
• probe configuration active during the incident.

Only Microsoft support can correlate an unexplained historical incident with retained platform-side telemetry that is not exposed in the resource logs.

References

1. Health probes in Azure Container Apps
2. Architecture best practices for Azure Container Apps
3. Troubleshoot health probe failures in Azure Container Apps
4. Diagnose and solve problems in Azure Container Apps
5. Troubleshoot common deployment failures in Azure Container Apps (azure-portal)
6. Monitor Azure Container Apps metrics
7. Set up alerts in Azure Container Apps