Container Apps Express adds a fixed ~500 ms to every inbound HTTP request

Question

Container Apps Express adds a fixed ~500 ms to every inbound HTTP request

JanCwiekala-8979 0

Problem

Every HTTP request to an app in an Azure Container Apps Express environment is delayed by a fixed ~500 ms before it reaches the container. The same image in a standard (Consumption) environment in the same region answers in 19–46 ms. The app itself handles each request in 2–3 ms.

Environment

Region: Germany West Central (also reproduced in Poland Central and Sweden Central; another customer reports the same in Australia East)
Java 25 / Spring Boot 4.1 native image
minReplicas 0 and 1, HTTP/1.1 and HTTP/2

Measurements

Region	Express (time to first byte)	Standard (time to first byte)	Express adds (minimum)
Poland Central	534 ms	19 ms	507 ms
Sweden Central	562 ms	46 ms	508 ms
Germany West Central	552 ms	40 ms	506 ms

Same image, 100 requests over one reused connection (no DNS, TCP or TLS setup).

Requests matched with the app's own log lines reach the container about 500 ms after being sent, are handled in 2–3 ms, and the response arrives about 45 ms later. The delay is before delivery to the replica.
The delay is the same with Microsoft's quickstart image and through Azure Front Door. The Australia East customer also sees it with a private endpoint and for app-to-app calls inside one Express environment.
Support diagnostics found no probe, ingress, DNS, SNAT or configuration issue.

Questions

Is this fixed per-request delay expected on Express?
Is a fix planned?
Is there any configuration that removes it?

A standard environment is not an option: its scale-from-zero takes 13–16 s before the container starts, against about 4 s on Express.

Public issue with full data: https://github.com/microsoft/azure-container-apps/issues/1856

0 comments

1 answer

Your answer

Answer 1

Hello @JanCwiekala-8979

The consistent ~500 ms delay on warm, reused connections is not documented as expected Azure Container Apps Express behavior. Express is suitable for HTTP APIs and optimized for fast startup, but it doesn't have a fixed per-request ingress delay or a setting that controls one.

The same behavior is tracked in the Microsoft Azure Container Apps GitHub repository as issue #1856. Tests there reproduce approximately 500 ms of additional latency across multiple regions, including app-to-app and private-endpoint traffic. However, the issue is still open and marked Needs: triage, so this is not yet an official confirmation of a platform defect, root cause, or planned fix.

Since the delay occurs with minReplicas: 1 and after connection establishment, the provided results do not indicate scale-from-zero, TCP setup, or TLS negotiation as the cause. Microsoft’s documentation does not provide a supported Express setting for bypassing its managed ingress path; Express app-to-app communication also uses the apps’ public URLs rather than internal service discovery.

To confirm your subscription, use Diagnose and solve problems and review the HTTP Requests, networking, replica-count, and environment-health detectors. These detectors are for ingress and performance investigations.

I recommend opening an Azure support request with:

Express and standard app resource IDs
Region and timestamps in UTC
Warm-request timing results
Confirmation that the same image and replica configuration were used
A reference to GitHub issue #1856

Until Microsoft completes its investigation, I cannot find verified official documentation to support a definitive answer on whether the delay is intentional, whether migrated environments are affected, or when it will be corrected. For latency-sensitive production APIs, using a standard workload-profiles environment is the documented option when greater networking and infrastructure control is required.

References:

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.

Jan Cwiekala 0 Reputation points

2026-11-02T15:37:36.76+00:00

Thanks for the answering.

Actually, GitHub issue #1856 was created by me. I also have support request 2611020050001222 open. On the Developer plan that request routed me here, and I can't reply on the case any more, so this post is the only open channel. I won't upgrade to a paid support plan just to escalate a defect in the platform.

The request and the issue already have what you list: both apps' resource IDs, UTC timestamps, warm-request timings on reused connections, and the same image and replica settings in both environments. The detectors found nothing.

A standard environment doesn't solve it for us. Its scale-from-zero takes 13–16 s before the container starts, against about 4 s on Express.

If you have a route to the Container Apps product team, could you pass this on so #1856 gets triaged? A second customer has since reported the same fixed delay in Australia East.
Allan Solomon Mejia 10,640 Reputation points

2026-11-02T15:50:45.9966667+00:00

Thanks for clarifying. I don’t have access to Azure support case 2611020050001222, and Microsoft Q&A contributors cannot route cases internally. However, Microsoft Q&A moderators can help with this.
Tejaswini Billakurthi 770 Reputation points Microsoft External Staff Moderator

2026-11-02T19:26:22.6166667+00:00

Hello @Jan Cwiekala ,

Thank you for reaching out to Microsoft Q & A!

Thank you for the details and for sharing GitHub issue #1856. Since you've already created support request 2611020050001222, the support engineer assigned to that request will help you further and will follow up with you directly.

Thank you for your patience.