Azure Service Bus "Outgoing Messages" metric drops to zero while messages are still being processed

Question

Azure Service Bus "Outgoing Messages" metric drops to zero while messages are still being processed

Joakim Hanstad Bendixen 20

We have an Azure Service Bus queue (Standard tier, North Europe) that has run in production for years without issue. Recently the Outgoing Messages metric suddenly dropped to zero and stopped reporting — but messages are clearly still flowing, since our consumer keeps processing them normally.

Setup

Service Bus queue, Standard tier
Consumer is a Service Bus–triggered Azure Function, Linux, App Service plan P2v3 (Dedicated)
Single instance, no auto-scale / scale-out — exactly one receiver connection to the queue
FUNCTION_EXTENSION_VERSION = ~4 (host runtime floats within major v4)

Symptoms

At a specific timestamp, Outgoing Messages (viewed as Sum over time) dropped to zero and stayed there.
Incoming Messages continues to report normally throughout — only Outgoing Messages is affected.
Messages are still delivered and processed by the function; active message count stays low and nothing is dead-lettered. No message loss observed.
No deployments in the last month — our code and configuration are unchanged.
We restarted the Azure Function once. Outgoing Messages resumed and reported correctly for ~2 hours, then returned to zero on its own.

So the data path is healthy — this looks like a metric/telemetry problem, not a message-flow problem.

Questions

Has anyone seen the Outgoing Messages metric stop emitting like this while delivery continues normally? Is it a known issue?
Since a restart temporarily restores the metric, is the metric emission tied to the receiver's underlying connection/backend node, and getting orphaned on AMQP link auto-recovery or a Service Bus node migration?
Is there any way to keep the metric reporting reliably (short of periodically restarting the Function), or a recommended alternative metric to monitor delivery/throughput? We have an Azure Service Bus queue (Standard tier, North Europe) that has run in production for years without issue. Recently the Outgoing Messages metric suddenly dropped to zero and stopped reporting — but messages are clearly still flowing, since our consumer keeps processing them normally.

Vallepu Venkateswarlu 10,590 Reputation points Microsoft External Staff Moderator

2026-07-06T10:47:50.2733333+00:00
Hi Joakim Hanstad Bendixen,

Welcome to Microsoft Q&A Platform.

From what you’re describing, this does sound like a monitoring/metrics ingestion or charting artifact rather than a message-path issue especially since messages are still being consumed/processed normally, there’s no dead-lettering, and restarting the Function temporarily “brings back” the Outgoing Messages metric.

Can you please share the below details for further troubleshooting.

In the portal chart, what time range and aggregation/granularity are you using when you see Outgoing Messages drop to zero?

Is this definitely a Queue metric (not a Topic subscription), and is there any autoforwarding involved?

Around the timestamp, do you see any spikes in Throttled Requests, Server Errors, or User Errors for the namespace/entity?

Are you viewing metrics at the entity level (queue) or namespace level? (And are you selecting the correct metric “Outgoing Messages” vs another “Outgoing*” graph?)

Does Outgoing Messages recover automatically if you wait (i.e., does it “catch up” later), or does it only recover after Function restart?

Are the messages being received via the Function using the same entity and subscription/receiver settings as before (no config drift), especially around session requirements or filters (if applicable)?
Joakim Hanstad Bendixen 20 Reputation points

2026-07-06T11:00:04.1033333+00:00
Hi,

I see the following (See also attached screenshot)

2026-07-05 20:29 UTC**:** Outgoing Messages (viewed as Sum over time) dropped to zero.

2026-07-06 06:24 (UTC): Function restarted and outgoing messages works again

2026-07-06 08:19 (UTC): Outgoing Messages dropped to zero again.

It is a Queue metric named "Outgoing messages"

I see no errors around the timstamps

The metrics are at entity level (queue). I'm selecteing "Outgoing messages" and "Incomming messages" in the graph

It does not recover within 10 hours, but did recover at Function restart, but lost it again after ~2 hours

Yes, it is the same function and same entity. No settings or code updated. We are not using sessions on this queue or any filters
Vallepu Venkateswarlu 10,590 Reputation points Microsoft External Staff Moderator

2026-07-06T12:40:37.1033333+00:00
Hi Joakim Hanstad Bendixen,

Thank you for the detailed information.

Based on this information, the Service Bus messaging path appears to be healthy, while the behavior is isolated to the Outgoing Messages metric reporting.

To investigate this further, we'll need to review the platform telemetry for the Service Bus namespace using the timestamps you've provided. We'll analyze the backend logs to determine why the metric stopped reporting while message delivery continued normally.

Thank you for sharing the detailed timeline and please also share the below details in private message and create a support to investigate with backend Team for further.

Note: Don't share the below details in public forum, make sure to share via Private message only

Service Bus Namespace name

Queue name

Azure Function App name

Region: North Europe

Metric affected: Outgoing Messages

Timeline:

2026-07-05 20:29 UTC – Metric stopped reporting

2026-07-06 06:24 UTC – Function restart restored metric

2026-07-06 08:19 UTC – Metric stopped again

Confirmation that:

Incoming Messages metric continues normally

Message processing is unaffected

No errors, throttling, or DLQ activity

No configuration or code changes

Single receiver, no sessions, Standard tier

We'll use this information to correlate the backend telemetry and investigate why the metric stopped reporting while message processing continued successfully.
Joakim Hanstad Bendixen 20 Reputation points

2026-07-07T09:26:57.9166667+00:00
Thanks for the analysis. Before the Teams call, could you please share the underlying diagnostic data so we can line it up against our own telemetry:

The exact detector output that produced the 200OKWorkers / 404Workers / 500Workers / 502Workers / 503Workers breakdown — ideally an export or screenshot — for the window 2026-07-05 18:00 UTC to 2026-07-06 14:00 UTC. Please also tell us which detector it came from (e.g. Worker Process Availability / Application Health) so we can view it ourselves under Diagnose and solve problems.

The Singleton lock acquisition failure log entries you referenced — timestamps and full messages — for the same window.

On our side, for that same window, Application Insights shows:

Continuous, successful function executions with no gaps.

No failures and no exceptions except one Singleton lock acquisition failure**.**

No dead-lettered messages, and Incoming Messages reporting normally throughout.

This is difficult to reconcile with an unhealthy or not-started runtime (404/500/502/503 workers) — if the host were down or unhealthy, message processing would have stopped, but it demonstrably continued. So we'd like to understand:

How do the worker-health signals you cite line up time-for-time with our continuous successful executions?

Were the 404/500/503 responses sustained, or transient health-ping blips that did not interrupt processing?

If processing was uninterrupted, what specifically caused the Outgoing Messages metric to stop emitting for hours while delivery continued — i.e., is that metric bound to the receiver's backend connection/link and being orphaned on link recovery or node migration?

Environment confirmation: we run a single Function App on a single storage account with one deployment slot. Name of function app is 28 characters and name of slot is 42 characters, so a Host ID collision does not apply here as they do not share 32 characters.
Vallepu Venkateswarlu 10,590 Reputation points Microsoft External Staff Moderator

2026-07-07T13:47:15.9466667+00:00
Hi Joakim Hanstad Bendixen,

Thank you for your detailed analysis and for correlating the Function App telemetry with the Service Bus metrics.

I reviewed the backend diagnostics for the timeframe you provided and observed the following:

The Function worker remained in a healthy state (200OK) throughout almost the entire period.

A single 404Worker event was observed around 2026-07-06 06:25 UTC, which aligns with the Function App restart. The runtime recovered immediately afterward, and there were no sustained 500, 502, or 503 worker states.

The diagnostics also recorded a single Singleton lock acquisition failure at 2026-07-06 06:25 UTC

The detector recommends reviewing Host ID considerations, as automatically generated Host IDs can conflict when multiple Function Apps or deployment slots share the same storage account.

Based on the environment details you've shared (single Function App, single storage account, one deployment slot), this recommendation doesn't appear to explain the behavior you're observing. Additionally, the backend diagnostics don't indicate a sustained Function runtime issue that would account for the Outgoing Messages metric stopping while message processing continued successfully.

Answer accepted by question author

Vallepu Venkateswarlu 10,590 Microsoft External Staff Moderator

Hi Joakim Hanstad Bendixen,

Thank you for sharing the details.

As discussed, the Service Bus namespace dashboard confirms that Outgoing Messages are being recorded successfully.

Based on investigation, Outgoing Messages are being recorded correctly on the Azure Service Bus platform, and the Azure Monitor metric is expected to reflect these values. However, the metrics are not being displayed correctly due to a change introduced in the June release. Our engineering team has identified the root cause and is currently deploying a fix that reverts the change introduced in the June release.

Pleaseand “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

0 comments

1 additional answer

Your answer

Vallepu Venkateswarlu 10,590 Reputation points Microsoft External Staff Moderator

2026-07-06T10:47:50.2733333+00:00

Hi Joakim Hanstad Bendixen,

Welcome to Microsoft Q&A Platform.

From what you’re describing, this does sound like a monitoring/metrics ingestion or charting artifact rather than a message-path issue especially since messages are still being consumed/processed normally, there’s no dead-lettering, and restarting the Function temporarily “brings back” the Outgoing Messages metric.

Can you please share the below details for further troubleshooting.

In the portal chart, what time range and aggregation/granularity are you using when you see Outgoing Messages drop to zero?

Is this definitely a Queue metric (not a Topic subscription), and is there any autoforwarding involved?

Around the timestamp, do you see any spikes in Throttled Requests, Server Errors, or User Errors for the namespace/entity?

Are you viewing metrics at the entity level (queue) or namespace level? (And are you selecting the correct metric “Outgoing Messages” vs another “Outgoing*” graph?)

Does Outgoing Messages recover automatically if you wait (i.e., does it “catch up” later), or does it only recover after Function restart?

Are the messages being received via the Function using the same entity and subscription/receiver settings as before (no config drift), especially around session requirements or filters (if applicable)?
Joakim Hanstad Bendixen 20 Reputation points

2026-07-06T11:00:04.1033333+00:00

Hi,

I see the following (See also attached screenshot)

2026-07-05 20:29 UTC**:** Outgoing Messages (viewed as Sum over time) dropped to zero.

2026-07-06 06:24 (UTC): Function restarted and outgoing messages works again

2026-07-06 08:19 (UTC): Outgoing Messages dropped to zero again.

It is a Queue metric named "Outgoing messages"

I see no errors around the timstamps

The metrics are at entity level (queue). I'm selecteing "Outgoing messages" and "Incomming messages" in the graph

It does not recover within 10 hours, but did recover at Function restart, but lost it again after ~2 hours

Yes, it is the same function and same entity. No settings or code updated. We are not using sessions on this queue or any filters
Vallepu Venkateswarlu 10,590 Reputation points Microsoft External Staff Moderator

2026-07-06T12:40:37.1033333+00:00

Hi Joakim Hanstad Bendixen,

Thank you for the detailed information.

Based on this information, the Service Bus messaging path appears to be healthy, while the behavior is isolated to the Outgoing Messages metric reporting.

To investigate this further, we'll need to review the platform telemetry for the Service Bus namespace using the timestamps you've provided. We'll analyze the backend logs to determine why the metric stopped reporting while message delivery continued normally.

Thank you for sharing the detailed timeline and please also share the below details in private message and create a support to investigate with backend Team for further.

Note: Don't share the below details in public forum, make sure to share via Private message only

Service Bus Namespace name

Queue name

Azure Function App name

Region: North Europe

Metric affected: Outgoing Messages

Timeline:

2026-07-05 20:29 UTC – Metric stopped reporting

2026-07-06 06:24 UTC – Function restart restored metric

2026-07-06 08:19 UTC – Metric stopped again

Confirmation that:

Incoming Messages metric continues normally

Message processing is unaffected

No errors, throttling, or DLQ activity

No configuration or code changes

Single receiver, no sessions, Standard tier

We'll use this information to correlate the backend telemetry and investigate why the metric stopped reporting while message processing continued successfully.
Vallepu Venkateswarlu 10,590 Reputation points Microsoft External Staff Moderator

2026-07-07T13:47:15.9466667+00:00

Hi Joakim Hanstad Bendixen,

Thank you for your detailed analysis and for correlating the Function App telemetry with the Service Bus metrics.

I reviewed the backend diagnostics for the timeframe you provided and observed the following:

The Function worker remained in a healthy state (200OK) throughout almost the entire period.

A single 404Worker event was observed around 2026-07-06 06:25 UTC, which aligns with the Function App restart. The runtime recovered immediately afterward, and there were no sustained 500, 502, or 503 worker states.

The diagnostics also recorded a single Singleton lock acquisition failure at 2026-07-06 06:25 UTC

The detector recommends reviewing Host ID considerations, as automatically generated Host IDs can conflict when multiple Function Apps or deployment slots share the same storage account.

Based on the environment details you've shared (single Function App, single storage account, one deployment slot), this recommendation doesn't appear to explain the behavior you're observing. Additionally, the backend diagnostics don't indicate a sustained Function runtime issue that would account for the Outgoing Messages metric stopping while message processing continued successfully.

Answer 1

kagiyama yutaka 5,410

I think Outgoing Messages is a sampled counter in Azure Monitor, and Azure shows delivery through the request metrics like Completed Messages and Successful Requests. and for steady monitoring u just switch your dashboard and alerts to those metrics; no code change, nothing risky.

Joakim Hanstad Bendixen 20 Reputation points

2026-07-06T11:06:05.6033333+00:00

Thanks for your comment. The Completed Messages has the exact same behavior as Outgoing Messages. It drops to zero at the same time. The Successful Requests shows the same pattern but as it includes the Incoming Messages, it does not drop to zero.
Unfortunately, I cannot use either metric.