Azure Service Bus - How to recover the connection / link dropped

Question

Azure Service Bus - How to recover the connection / link dropped

John Wong Yek Hon 295

The Background

My apps are currently suffer the connection / link dropped issue on the Azure Service Bus.

My apps are nodejs, deployed as Azure Container Apps, connect to Service Bus via the latest SDK. After running happily for long, recently we face issue on the stall receivers.

The receivers subscribe to different queues. We believe during the azure maintenance windows, the receivers suddenly no longer able receive message. And then it get auto recovered after around 15 minutes, without us doing anything.

The questions

Is it common? and the SDK by default won't handle it?
What's the best way to recover it, if we can't avoid some coding works? Could it be resolved by implement the recovery logic on the SDK's processError() function? Or must it be a watchdog to re-init the receivers? Or even other solutions?

Appreciate any expert advise.

Pravallika KV 18,850 Reputation points Microsoft External Staff Moderator

2026-07-02T21:36:41.3266667+00:00

@John Wong Yek Hon , following up to see if you had a chance to check the above response and if it was helpful.
John Wong Yek Hon 295 Reputation points

2026-07-06T05:51:16.3766667+00:00

We did some test simulate the network failure, and confirm that the SDK auto attempt to recover, and the attempt seems non-stop until it success. Could you confirm this?

If the SDK already attempt non-stop but still failed, would a watchdog approach able to recover the receiver link from external instead? Maybe you could share certain clue on how to make the recovery attempt different? Please advise.
Pravallika KV 18,850 Reputation points Microsoft External Staff Moderator

2026-07-08T14:34:14.64+00:00
Yes, your observation is correct. The Azure Service Bus Node.js SDK automatically retries and attempts to recover transient AMQP connection/link failures based on the configured retry policy. If the underlying network issue is resolved, the SDK should recover without requiring manual receiver recreation.

A watchdog can still be useful, but it does not make the SDK retry differently. If the SDK is already retrying continuously, recreating the receiver will likely face the same issue.

The watchdog approach is mainly useful when the receiver appears stuck and recovery is not progressing. In that case, it can force a clean restart:

Close the receiver/client.

Create a new ServiceBusClient.

Create a new receiver.

This creates a fresh AMQP connection and link.

1 answer

Your answer

Pravallika KV 18,850 Reputation points Microsoft External Staff Moderator

2026-07-02T21:36:41.3266667+00:00

@John Wong Yek Hon , following up to see if you had a chance to check the above response and if it was helpful.
John Wong Yek Hon 295 Reputation points

2026-07-06T05:51:16.3766667+00:00

We did some test simulate the network failure, and confirm that the SDK auto attempt to recover, and the attempt seems non-stop until it success. Could you confirm this?

If the SDK already attempt non-stop but still failed, would a watchdog approach able to recover the receiver link from external instead? Maybe you could share certain clue on how to make the recovery attempt different? Please advise.
Pravallika KV 18,850 Reputation points Microsoft External Staff Moderator

2026-07-08T14:34:14.64+00:00

Yes, your observation is correct. The Azure Service Bus Node.js SDK automatically retries and attempts to recover transient AMQP connection/link failures based on the configured retry policy. If the underlying network issue is resolved, the SDK should recover without requiring manual receiver recreation.

A watchdog can still be useful, but it does not make the SDK retry differently. If the SDK is already retrying continuously, recreating the receiver will likely face the same issue.

The watchdog approach is mainly useful when the receiver appears stuck and recovery is not progressing. In that case, it can force a clean restart:

Close the receiver/client.

Create a new ServiceBusClient.

Create a new receiver.

This creates a fresh AMQP connection and link.

Answer 1

Hi @John Wong Yek Hon ,

It sounds like you’re seeing Service Bus receivers stall / drop their AMQP link after some time, then recover automatically after ~15 minutes which lines up with the general idea that persistent connections/links can be closed during service-side changes (including maintenance) or due to inactivity/idle behavior, and that well-behaved clients should be able to recreate the link/connection and continue.

Is this common? And does the SDK handle it by default?

Yes, transient disconnections and reconnections are an expected part of working with persistent connections in Azure services. Routine maintenance and other interruptions can temporarily disconnect clients, and applications should be designed assuming connection interruptions will happen.

For Azure Service Bus specifically, the service upgrades/restarts can cause momentary throttling, drops in incoming messages/requests, and the application being disconnected for a few seconds. When you’re using the SDK, the guidance says the retry policy is built in and active, and the application reconnects without significant impact.

Also, with AMQP-based clients: some AMQP errors correspond to standard behaviors like link/connection closure and can be avoided by making send/receive calls in a way that uses the connection/link (which recreates them as needed).

So in short: this isn’t unusual, and your “auto recover after ~15 minutes” strongly suggests you’re already hitting some transient condition, but you may want to confirm your client is creating/maintaining receivers in the “intended” resilient way.

Best way to recover:

Ensure your app handles transient connectivity failures with retry/reconnect

Azure Service Bus reliability guidance emphasizes that client-side retry and reconnection logic is necessary when connections drop.

If the stall is truly on “receivers stop receiving until the link is re-established,” the practical mitigations typically fall into two approaches (both are reasonable patterns):

Lightweight reconnect logic that recreates the receiver/link when you detect it’s stuck.
A watchdog (application-level) that reinitializes receivers if no progress is observed for some interval.

Don’t rely only on processError() unless it triggers on the right failure mode

However, conceptually:

If processError() fires when the link/connection is closed or errors, it can be a good place to trigger receiver/link recreation.
If the receiver “stalls” without surfacing an error, then a pure error handler may not run so a watchdog based on “no messages / no settle / no handler progress” might be more reliable.

Check whether maintenance/restart symptoms match your timestamps

During backend upgrades/restarts:

active/disconnected behavior can occur for a few seconds
logs may contain error messages
the app can disconnect briefly

Your observation of ~15 minutes recovery suggests a longer client-side effect or an idle timeout/behavior, so it would be useful to correlate the incident time with any Azure Service Health / portal signals (see questions below).

Confirm the SDK retry policy / defaults are enabled and not overridden. The Service Bus troubleshooting guidance states that when using the SDK, retry policy is built-in/active.
Add a receiver health watchdog at the app layer (common resilient pattern):
- Track “message received” or “message handler invoked” timestamps per subscription/receiver.
- If nothing progresses for N minutes, close and recreate the receiver (or force link recreation depending on your SDK usage model).
If you already have processError()/error callbacks, make them explicitly trigger the same recovery path as the watchdog (e.g., receiver recreation), so both “error” and “silent stall” are covered.
Correlate with service health / any maintenance window using Azure Service Health.

Hope this helps!

If the resolution was helpful, kindly take a moment to click on User's image and click on Yes for was this answer helpful. And, if you have any further query do let us know.

Pravallika KV 18,850 Reputation points Microsoft External Staff Moderator

2026-07-11T07:39:51.4766667+00:00

@John Wong Yek Hon , Following up to see if the provided answer was helpful. If this answers your query, do click Accept Answer =>Yes, and upvote it. If you have any further queries do let us know.