Intermittent ETIMEDOUT and ServiceBusError while sending messages to Azure Service Bus Standard Tier Queue

Question

Intermittent ETIMEDOUT and ServiceBusError while sending messages to Azure Service Bus Standard Tier Queue

Md Farhaan 0

Hi Team,

We are encountering intermittent issues while sending messages to an Azure Service Bus Standard Tier queue (we are only using queues, no topics). Occasionally, we receive the following error: "ServiceBusError: [connection-1] Sender 'queuename-queueId' with address 'queuename', was not able to send the message right now, due to operation timeout."

Alongside this, we sometimes also see a low-level network error: "ETIMEDOUT: connect ETIMEDOUT <ip>". We are using the @azure/service-bus Node.js SDK in a production environment. This issue does not occur consistently but appears sometimes . We would like to understand what typically causes such timeouts in the Standard tier, whether it could be related to retry settings, network instability, or connection pooling, and if there are any best practices or configurations (such as for retries or connection reuse) to help avoid or mitigate this issue. Any guidance would be appreciated.

Also would like to understand service bus rate limits per second. I feel we might be crossing it which is causing the issue.

Thanks

1 answer

Your answer

Answer 1

Sai Prabhu Naveen Parimi 3,470 Microsoft External Staff Moderator

@Md Farhaan

The errors you're seeing, such as the ServiceBusError and the ETIMEDOUT network error, can indeed be caused by a number of factors.

Here are a few things to consider and some steps to mitigate the issue:

Network Instability: The ETIMEDOUT error often points to network issues. Ensure that your network connection is stable and check for any potential firewall rules that might be affecting connectivity.

Timeouts: Check the MessagingFactorySettings.OperationTimeout in your Service Bus configuration. If the operation is taking longer than this setting, it will throw a TimeoutException. It might help to increase this timeout duration if you are performing larger batch operations.

Connection Limits: The default connection limit may be reached if your application is creating too many concurrent connections. You can check the ServicePointManager.DefaultConnectionLimit value and adjust it if necessary.

Retries and Backoff: Ensure that you're implementing a robust retry logic with exponential backoff in your messaging code. This is important for transient failures and helps in avoiding repeated immediate retries that could lead to throttling or timeout issues.

Throttling: Since you're concerned about hitting Service Bus rate limits, consider monitoring the metrics in the Azure portal for your Service Bus namespace. Make sure to check the throttling policies and understand the load your application is generating. If throttling is a frequent issue, moving to a Premium tier might provide the required resources.

Best Practices Documentation: Incorporate information from the Azure documentation on Service Bus messaging exceptions and throttling operations for further insights.

Md Farhaan 0 Reputation points

2025-07-09T12:59:51.8066667+00:00

Hi @Sai Prabhu Naveen Parimi Thanks for the response. We are implementing Retries and Backoff. Where can I get values for MessagingFactorySettings.OperationTimeout and ServicePointManager.DefaultConnectionLimit values. We have implemented.
Md Farhaan 0 Reputation points

2025-07-09T13:18:39.82+00:00

Our active connections seems to be around ~600 only. Is there any other metric that is required to be monitored?
Sai Prabhu Naveen Parimi 3,470 Reputation points Microsoft External Staff Moderator

2025-07-09T13:33:07.1733333+00:00
@Md Farhaan

Great follow-up questions.

Where can I get values for MessagingFactorySettings.OperationTimeout and ServicePointManager.DefaultConnectionLimit?

These are specific to the .NET SDK, but since you're using the Node.js SDK (@azure/service-bus):

For operation timeout, you can configure this using retryOptions.timeoutInMs when initializing the ServiceBusClient. For example:

const sbClient = new ServiceBusClient(connectionString, { retryOptions: { timeoutInMs: 30000, // 30 seconds maxRetries: 5, retryDelayInMs: 1000 } });

Reference: "[Retry Options - Azure SDK for JavaScript]"

For connection limits, Node.js doesn’t use ServicePointManager. Instead:

Make sure you are reusing the ServiceBusClient and Sender objects.

Avoid creating new connections for every send operation.

The Service Bus Standard tier allows up to 1,000 concurrent connections per namespace.

Reference: "Azure Service Bus quotas and limits"

Our active connections are ~600 – is there anything else we should monitor?

Yes, in addition to active connections, I recommend monitoring the following metrics in the Azure portal:

ThrottledRequests

IncomingRequests

Successful vs Failed Requests

Queue length and Dead-lettered Messages

Message size and throughput

Connection Open Rate (if available)

Reference: "Monitor Azure Service Bus with Azure Monitor" –

Also, enabling diagnostics logs can give you more detailed visibility:

Reference: "Azure diagnostic settings for Service Bus"
Md Farhaan 0 Reputation points

2025-07-09T16:00:02.6166667+00:00

Thanks will implement the changes and monitor the results!
Sai Prabhu Naveen Parimi 3,470 Reputation points Microsoft External Staff Moderator

2025-07-09T17:23:15.5433333+00:00

@Md Farhaan

Sure !! Thank you for the update
Sai Prabhu Naveen Parimi 3,470 Reputation points Microsoft External Staff Moderator

2025-07-11T03:22:12.4266667+00:00

@Md Farhaan

Just following up to confirm if everything is functioning as expected after the recent changes. Please share your feedback.

Share via

Intermittent ETIMEDOUT and ServiceBusError while sending messages to Azure Service Bus Standard Tier Queue

1 answer

Your answer