Azure Container Apps: Is disabling ingress the correct fix for background worker apps failing startup probes?

Mishra, Yogesh 0 Reputation points
2026-09-03T14:47:36.0633333+00:00

Context & Environment We are setting up an application infrastructure using Azure Container Apps (ACA) with multiple containers handling different roles:

API Handlers (1–2 apps): HTTP-triggered services that fetch/process data from a database and return responses.

  • Worker Services (Majority of apps): Background workers triggered asynchronously via event buses, queues or background processors.

The Problem In our test environment, everything worked as expected. However, in production, all background worker container apps continuously enter a failing state after deployment:

The container app deploys, starts, and processes events normally for about 4 minutes.

  1. It suddenly stops with the status Activation Failed.

Root Cause Identified Upon inspecting the logs, the failure is caused by the default Startup Probe configuration. Azure Container Apps is configured to perform a TCP health check/probe on port 8080. Because our background workers are purely event-driven (queue/message listeners) and do not host an HTTP/TCP server, they do not open or listen on port 8080. The startup probe fails the TCP check, leading the ACA runtime to terminate the replica.

Workaround & Main Question We found that disabling Ingress completely for these worker container apps stops ACA from enforcing the HTTP/TCP startup probe, which resolves the crash loop.

However, we are unsure if completely disabling ingress is the recommended production practice for event-driven ACA workers, or if this introduces hidden drawbacks.

Questions for the Community:

Is disabling ingress the idiomatic/recommended architectural pattern for non-HTTP worker containers in Azure Container Apps?

  1. Does disabling ingress impact KEDA scaling, metrics collection or health monitoring for queue-based apps?
  2. If ingress should remain enabled, what is the best practice for configuring probes (e.g., custom liveness/readiness TCP endpoints, dummy web servers)?
Azure Container Apps
Azure Container Apps

An Azure service that provides a general-purpose, serverless container platform.

0 comments

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Tejaswini Billakurthi 270 Reputation points Microsoft External Staff Moderator
    2026-09-07T12:02:42.6166667+00:00

    Hello @Mishra, Yogesh ,

    Thank you for reaching out to Microsoft Q&A!

    Disabling ingress is the documented approach for container apps that do not receive inbound traffic. The troubleshooting guidance states that if the app does not serve HTTP, such as a background worker, you should consider disabling ingress or using internal ingress so that no HTTP probe is enforced.

    Your analysis of the cause also matches the documented default probe behaviour. When ingress is enabled and no probes are defined, Container Apps adds a default TCP startup probe against the ingress target port with a period of 1 second and a failure threshold of 240, which works out to approximately four minutes — consistent with the timing you observed.

    Reference: Health probes in Azure Container Apps — Default configuration

    Two points are worth confirming when ingress is disabled, as these are easy to miss:

    1. Replica configuration

    Ensure each worker app has either a custom scale rule or minReplicas set to 1 or higher. The documentation notes that if ingress is disabled and neither minReplicas nor a custom scale rule is defined, the container app scales to zero and has no way of starting back up. This is worth confirming on each worker app.

    1. Revision mode

    For non-HTTP event scale rules, set properties.configuration.activeRevisionsMode to single.

    Reference: Set scaling rules in Azure Container Apps

    Regarding your specific questions:

    • Queue and event-driven scale rules are evaluated against the configured event source and are not dependent on ingress being enabled. Only HTTP and TCP scale rules require ingress.
    • Metrics and log collection are not tied to ingress and continue to work normally.
    • Adding a placeholder web server purely to satisfy probes is not documented as a recommended pattern. If ingress must remain enabled for a specific app, define explicit probes that match the port the application actually listens on rather than relying on the default probe configuration.

    Please "Upvote the Answer" if this information helped you. This will help us and others in the community as well.

    Was this answer helpful?

    2 people found this answer helpful.
    0 comments
  2. kagiyama yutaka 5,330 Reputation points
    2026-09-03T23:35:31.5033333+00:00

    I think ACA adds a TCP startup probe when ingress is turned on, and any worker that never opens that port will just fail it. So if that worker doesn’t expose the port, you either turn ingress off or define your own probes in YAML/Bicep to override the default one.

    Was this answer helpful?

    0 comments

  3. AI answer

    2026-09-03T14:48:01.0133333+00:00

    Yes. For background worker container apps that do not accept HTTP or TCP traffic, disabling ingress is the recommended pattern.

    Why this fits the scenario:

    1. When ingress is enabled, Azure Container Apps can apply default probes. If the app does not listen on the configured target port, probe failures can cause the replica to restart or the revision to become degraded.
    2. The documented guidance for startup failures explicitly says that if the app does not serve HTTP, such as a background worker, disabling ingress or using internal ingress should be considered so that no HTTP probe is enforced.
    3. The accepted Microsoft Q&A guidance in the same scenario states that if the app is a worker with no listener, set ingress to Disabled to avoid the default startup probe and restarts.

    For the specific questions:

    • Is disabling ingress idiomatic for non-HTTP workers?
      Yes. For queue-, event-, or bus-driven workers that do not expose a network endpoint, disabling ingress is the appropriate production configuration.
    • Does disabling ingress affect KEDA scaling, metrics collection, or queue-based processing?
      No impact is stated in the provided material for queue-based scaling or metrics collection. The guidance only ties ingress to reachability and probe behavior. One documented scaling-related requirement is that if a scaling rule depends on reaching an external signal source, that source must be reachable from the app.
    • If ingress remains enabled, what is the best practice?
      If ingress must stay enabled, configure probes so they match actual app behavior:
      1. Make sure the probe port matches the app’s listening port and the ingress targetPort.
      2. If startup is slow, increase initialDelaySeconds and use a startup probe with a higher failureThreshold.
      3. For HTTP probes, use a health endpoint that returns HTTP 200.
      4. For TCP probes, verify the app really listens on that port.

    For the current worker apps, adding a dummy web server just to satisfy probes is not supported as a best practice in the provided material. The supported guidance is simpler: disable ingress when the app is not intended to receive inbound traffic.

    A practical production split is:

    • API handlers: enable ingress and configure health probes to match the exposed endpoint.
    • Background workers: disable ingress unless they truly need inbound traffic.

    If changes are needed, ingress can be disabled with:

    az containerapp ingress disable \
    --name <app-name> \
    --resource-group <resource-group> \
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.