Share via

Slow request routing with App Service for Containers

Andreas Roth 20 Reputation points
2026-03-16T13:37:29.9+00:00

Hello everyone,

for the last week, I have been diving into a rabbit whole of improving performance for my web app hosted in a Docker Container on Azure App Service.

I set up alerts for metrics so that I get notified when the response time of my app starts to degrade. Now I saw something really curious: Last saturday, at 07:23 AM, the metrics say, my app took on average 55 seconds to answer requests over 334 requests. However, the request logs within my container show not one request that took longer than 1 second. Since I was sound asleep at that time, I do not now wether the performance was really degraded for real users or if this was a measurement artifact.

Since it was a Saturday, no admin was online that could have the log stream open, so that could not have affected the response time.

How could I possibly debug, what requests took that long?

Azure App Service
Azure App Service

Azure App Service is a service used to create and deploy scalable, mission-critical web apps.

Answer accepted by question author
  1. Golla Venkata Pavani 3,920 Reputation points Microsoft External Staff Moderator
    2026-03-18T13:30:57.5633333+00:00

    Hi @Andreas Roth ,

    Thank you for reaching us regarding the issue.

    The App Service for Linux/containers that trips up a lot of folks. The Average Response Time metric you're seeing in Azure Monitor measures the entire journey: from the moment the request hits Azure's front-end load balancer, through proxying to your container, your app's processing time, and back out. Your container logs only start timing once the request is handed off to your code inside the Docker container. That's why you can see 55 s on the platform side while every request in your logs finishes in under a second.

    To figure out exactly what happened:

    1. Start with the built-in diagnostics:
      In your App Service blade, go to Diagnose and solve problems > Availability and Performance. Run the detectors, they automatically correlate the platform metrics with your container activity and will flag queuing, proxy delays, or brief spikes.
    2. Enable Monitoring > Diagnostic settings > App Service diagnostic logs, specifically Web Server (HTTP) logs, and send them to Log Analytics or Storage. These logs show the platform’s view of each request, including the actual time taken, even if the request never reached the container.
    3. Optionally, use Application Insights to capture application‑level timing and correlate it with platform metrics to confirm whether latency occurred before or inside the app.

    Reference:
    https://learn.microsoft.com/en-us/azure/app-service/troubleshoot-diagnostic-logs
    https://learn.microsoft.com/en-us/azure/app-service/monitor-app-service?tabs=aspnetcore
    https://learn.microsoft.com/en-us/azure/app-service/overview-diagnostics

    Kindly let us know if the above helps or you need further assistance on this issue.

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

    1 person found this answer helpful.
    0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Q&A Assist
    2026-03-16T13:37:55.72+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    Use App Service diagnostics and logging to correlate what Azure saw as 55‑second requests with what the container processed.

    1. Enable and review platform-side logs
      • In the Azure portal, open the App Service.
      • Under Monitoring → Metrics, add:
        • Response time
        • Requests
        • CPU and memory metrics
      • Zoom into the exact time window (around Saturday 07:23) and check whether:
        • Response time spikes align with CPU/memory pressure.
        • Request count or other metrics (like throttling) changed.
      • If not already enabled, turn on web server diagnostics so Azure can log what IIS/HTTP front end sees, not just what the container logs:
        • Enable Web Server Logging, Detailed Error Logging, and Failed Request Tracing for the App Service.
    2. Collect detailed traces for slow/failed requests
      • Use Failed Request Tracing to capture per-request timing through the pipeline. This is useful when Azure reports slow responses but the app/container logs do not.
      • To gather traces:
        1. In the Azure portal, go to the web app.
        2. Go to Diagnostics Logs and turn Failed Request Tracing to On, then Save.
        3. Use Kudu to download the trace files:
          • In the app blade, select Tools → Kudu → Go.
          • In Kudu, go to Debug Console → CMD.
          • Open the LogFiles folder, then the folder starting with W3SVC.
          • Inspect the XML trace files (pencil icon) to see which URLs and components consumed time.
    3. Use Application Insights Profiler for code-level timing
      • If Application Insights is configured for the app, enable Application Insights Profiler:
        • Profiler captures detailed performance traces and shows response time per call and which code paths are slow.
        • It keeps traces for up to five days, so it can be used shortly after an incident to inspect slow requests.
      • Profiler helps confirm whether the delay is inside the container code or elsewhere (for example, network or platform).
    4. Monitor endpoint health and external behavior
      • Configure endpoint monitoring (Standard tier or higher):
        • App Service can run HTTP GET tests from multiple regions every 5 minutes.
        • A test fails if the HTTP status is ≥ 400 or the response takes more than 30 seconds.
      • This helps confirm whether real external clients experienced long response times or whether the spike was limited to internal measurements.
    5. Mitigate and protect against future spikes
      • If the spike correlates with resource saturation or many concurrent requests, consider:
        • Scaling up the App Service plan to a higher tier.
        • Scaling out to more instances so load is spread and individual requests are less likely to queue.
      • Configure auto-heal to recycle the worker process when requests exceed a given execution time or when memory/CPU thresholds are hit.
      • As a last resort during an incident, a restart of the app from the portal can clear transient issues.

    By combining platform logs (Failed Request Tracing, web server logging), Application Insights Profiler, and Metrics/endpoint monitoring, it becomes possible to identify whether the 55‑second average was due to queued/blocked requests at the platform level, transient service issues, or actual slow processing inside the container.

    References:

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.