Azure App Service (Linux) WebJob - Getting an ApplicationInsights QuickPulseSender error in prod but not dev

Howard 0 Reputation points
2026-10-30T21:44:08.4166667+00:00

Hi, I have prod and dev environments set up in Terraform and have virtually identical configurations with the exception of a few config differences (prod has a higher tier plan and is in us-central instead of us-west).

I have an App Service (linux) setup that runs a WebJob (which runs a bash script) every hour. On dev, this runs fine with no error. On prod, the following error is being emitted every time, and sometimes it prevents the WebJob from completing (so it's stuck in Running state some of the time).

The ApplicationInsights:QuickPulseSender appears to be automatically executed by the WebJob runner (and is not run by my code).

As far as I can tell, there is no outbound rule setup that would be blocking this connection (and the rules should be the same from dev to prod).

Not sure what the cause is - any help would be appreciated.

[10/30/2026 21:05:12 > dcd7eb: ERR ] ApplicationInsights:QuickPulseSender [
[10/30/2026 21:05:12 > dcd7eb: ERR ]   'Live Metrics endpoint could not be reached 25 consecutive times. Most recent error:',
[10/30/2026 21:05:12 > dcd7eb: ERR ]   Error: connect ETIMEDOUT 20.40.206.232:443
[10/30/2026 21:05:12 > dcd7eb: ERR ]       at TCPConnectWrap.afterConnect [as oncomplete] (node:net:2083:16)
[10/30/2026 21:05:12 > dcd7eb: ERR ]       at TCPConnectWrap.callbackTrampoline (node:internal/async_hooks:131:17) {
[10/30/2026 21:05:12 > dcd7eb: ERR ]     errno: -110,
[10/30/2026 21:05:12 > dcd7eb: ERR ]     code: 'ETIMEDOUT',
[10/30/2026 21:05:12 > dcd7eb: ERR ]     syscall: 'connect',
[10/30/2026 21:05:12 > dcd7eb: ERR ]     address: '20.40.206.232',
[10/30/2026 21:05:12 > dcd7eb: ERR ]     port: 443
[10/30/2026 21:05:12 > dcd7eb: ERR ]   }
[10/30/2026 21:05:12 > dcd7eb: ERR ] ]
Azure App Service
Azure App Service

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

0 comments

1 answer

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-10-30T21:45:14.17+00:00

    The production App Service must be able to resolve and reach its regional Application Insights Live Metrics endpoint over TCP 443/TLS 1.2; test that path from the production Kudu environment rather than assuming its effective routing matches development.

    Test the failing path from production

    QuickPulse is the Application Insights Live Metrics component. Live Metrics uses different endpoints from normal telemetry, so successful log or telemetry ingestion does not prove that QuickPulse connectivity works.^1^

    1. Open App Service → Development Tools → Advanced Tools → Go.
    2. In Kudu, select Tools → Debug Console → CMD.
    3. Test DNS and HTTPS from both production and development:
    nslookup <region>.livediagnostics.monitor.azure.com
curl -v --connect-timeout 20 \
  https://<region>.livediagnostics.monitor.azure.com

    These are the documented Linux App Service tests for DNS and outbound connectivity.^2^

    Use the region encoded in the Application Insights connection string rather than assuming it matches the App Service region. Also test the applicable global Live Metrics hosts if they appear in DNS or network logs:

    • live.applicationinsights.azure.com
    • rt.applicationinsights.microsoft.com
    • rt.services.visualstudio.com
    • <region>.livediagnostics.monitor.azure.com

    All require outbound port 443; the regional Live Metrics endpoint currently uses IPv4.^3^

    A successful curl may return an HTTP response that is not useful to a browser; the important results are successful DNS resolution, TCP connection, and TLS negotiation. A connection timeout matching the WebJob error confirms an effective network-path problem.

    Compare the effective production path

    Since the Terraform resources are nearly identical, compare the settings that can change the actual route:

    • VNet integration and WEBSITE_PRIVATE_IP
    • Route All
    • Integration-subnet NSG rules
    • User-defined routes
    • Azure Firewall or network virtual appliance rules
    • Custom DNS server settings
    • Proxy environment variables
    • Application Insights connection strings and endpoint suffixes
    • Any Azure Monitor Private Link Scope/private DNS association

    For a VNet-integrated Linux app, run:

    set | grep WEBSITE_PRIVATE_IP
set | grep -E 'WEBSITE_DNS|HTTP_PROXY|HTTPS_PROXY|NO_PROXY'
nslookup <region>.livediagnostics.monitor.azure.com
curl -v https://<region>.livediagnostics.monitor.azure.com

    If production resolves the hostname differently from development, correct its DNS/private-link configuration. If resolution matches but only production times out, inspect the production subnet’s UDR, NSG, firewall, and Route All path. Prefer an AzureMonitor service-tag rule where supported instead of allowing the single logged IP, because endpoint addresses can change.^3^

    If the failure is intermittent

    Intermittent timeouts that coincide with other outbound failures can indicate SNAT or TCP connection exhaustion. In the portal, open:

    App Service → Diagnose and solve problems → Availability and Performance → SNAT Port Exhaustion

    App Service instances initially receive 128 preallocated SNAT ports, and repeated new connections to the same destination address and port can temporarily exhaust them.^4^

    If diagnostics confirm exhaustion, the supported mitigations include connection reuse/pooling, scaling out, private endpoints where applicable, or routing outbound traffic through a NAT gateway. Do not apply these merely from the QuickPulse message; first confirm correlated SNAT failures.

    Disabling Live Metrics, if it is not required

    Only disable Live Metrics if the component is created by instrumentation that you control. For the Azure Monitor OpenTelemetry Node.js distro, Live Metrics defaults to enabled and can be disabled with enableLiveMetrics:^5^

    {
  "enableLiveMetrics": false,
  "enableStandardMetrics": true
}

    Point APPLICATIONINSIGHTS_CONFIGURATION_FILE to that JSON if using a custom configuration file. This setting is not established as a supported switch for the Kudu WebJob runner itself, so first identify whether the parent App Service’s Node/OpenTelemetry instrumentation is producing the message.

    Finally, verify the WebJob’s own exit path separately in App_Data/jobs/<type>/<jobname> or its execution history. Kudu owns WebJob execution logging, and a WebJob remaining Running can also mean that the script—or a child process it launched—never exited, even when the last visible message came from QuickPulse.^6^

    References

    1. Troubleshoot Live Metrics Issues - Azure | Microsoft Learn
    2. Troubleshoot virtual network integration with Azure App Service
    3. Azure Monitor endpoint access and firewall configuration
    4. Troubleshoot intermittent outbound connection errors in Azure App Service
    5. Azure Monitor OpenTelemetry for JavaScript
    6. How WebJobs run in Azure App Service
    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.