Edit Thresholds
Tip
Edit the Monitoring thresholds for the selected Azure Service Bus Queue or Azure Service Bus Topic Subscription.
Nodinite empowers you to actively manage Monitoring thresholds for your Azure Service Bus Queues and Topic Subscriptions. This page guides you through editing resource-specific settings to optimize performance, reliability, and alerting.
Expect to:
- ✅ Gain full control over Monitoring thresholds for proactive management
- ✅ Override global settings with resource-specific configurations
- ✅ Enhance reliability with tailored alerting and automated actions
- ✅ Leverage Nodinite's intuitive interface for seamless configuration
Use the Edit thresholds page to change the Monitoring thresholds. When untouched, the Monitoring is using the global settings which you can change using the Remote Configuration. You can override these individually for each queue or topic subscription.
You can modify the following properties:
- Description - Brief Nodinite specific description of the queue.
- Delete message on resubmit - When checked, delete the original message by default after a successful resubmit operation.
- Allowed timespan - Evaluate the age of the first message on the queue. Warning and Error alerts are triggered based on the age of the first message on the queue.
- Queue Count Evaluation Type:
- None - Count-based Monitoring is disabled.
- Fixed - Evaluate the Monitoring based on the number of messages on the queue.
- Percentage - Evaluate the Monitoring based on the current size vs the maximum allowed size of the queue.
- Comes First - Both the Fixed and Percent options are enabled and the Monitoring yields alerts on what happens first.
- Delivery Count - Monitor message delivery attempts to detect problematic messages before Azure Service Bus dead-letters them. Available for both Queues and Topic Subscriptions.
- Auto-forwarding - Decide whether active messages remaining on an entity with Forward To set yield OK, Warning, or Error, or use the configured thresholds. See Forward To for Queues and Topic Subscriptions.
- Acknowledge Dead-Letters - Report existing dead-letter messages as Warning instead of Error, while new dead-letter messages still raise Error.
Click the Edit thresholds menu item in the Actions button on the selected queue to open the Edit modal.
Example of the 'Edit thresholds' menu item in the Actions button menu.
The top part of the Edit modal shows the Resource details, the Description, the Delete Message on Resubmit checkbox, and the Allowed Timespan and Message Count panels.
The top part of the Edit modal for a Service Bus Queue. The Resource details include Forward to, Forward to (Dead Letter), and Dead-letter messages acknowledged.
Scroll down to the Delivery Count, Auto-forwarding, and Acknowledge Dead-Letters panels and the Save button.
The bottom part of the Edit modal for a Service Bus Queue, here with Delivery Count monitoring set to None and Auto-forwarding evaluation set to Raise Warning.
The Edit modal for a Topic Subscription has the same panels. The top part groups the Allowed Timespan and Message Count panels under Topic Subscription Monitoring Thresholds; see Managing Azure Service Bus Topic Subscriptions.
If you see the following alert, this queue is using global thresholds. When you click the Save button, the queue starts to use specific thresholds instead: "By clicking Save, this queue will be monitored using the specific configuration instead of the global configuration."
Example of the alert indicating the queue is using global thresholds.
Click the Save button to persist changes.
Example of the 'Save' button to persist changes.
Queue Description
You can manage the Description field for the Nodinite Resource. This option provides you a way to add a "comment" for the specific queue.
Delete message on resubmit
When checked, delete the original message by default after a successful resubmit operation. The User can override this setting on individual resubmit operations.
Timespan evaluation
- Allowed timespan - manage threshold for the maximum allowed age for the first message on the specific queue
| State | Name | Data Type | Value Example | Description |
|---|---|---|---|---|
| ⚠️ Warning | Warning TimeSpan | Timespan | 00:05:00 (5 minutes) | The age of the first message on the queue to trigger Warning alert |
| ❌ Error | Error TimeSpan | Timespan | 01:10:00 (1 hour 10 minutes) | The age of the first message on the queue to trigger Error alert |
Count Based Evaluation
The queue based Monitoring is a powerful feature that allows you to monitor the number of messages in your Azure Service Bus Queue. This feature can help you ensure that your queues are not overloaded and that messages are processed in a timely manner.
| State | Name | Data Type | Value Example | Description |
|---|---|---|---|---|
| ⚠️ Warning | Warning Count | integer | >=0 | The number of messages to go above on the queue to trigger Warning alert |
| ❌ Error | Error Count | integer | >=0 | The number of messages to go above on the queue to trigger Error alert |
| ⚠️ Warning | Warning Limit % | integer | 1-100 | Set the threshold quota value in percentage (1-100) to trigger Warning alert |
| ❌ Error | Error Limit % | integer | 1-100 | Set the threshold quota value in percentage (1-100) to trigger Error alert |
Queue Count Evaluation Type
There are four different types of count-based evaluations:
- None - Count-based Monitoring is disabled.
- Fixed - Evaluate the Monitoring based on the number of messages on the queue.
- Percentage - Evaluate the Monitoring based on the current size vs the maximum allowed size of the queue.
- Comes First - Both the Fixed and Percent options are enabled and the Monitoring yields alerts on what happens first.
Example of the 'Count Evaluation Type' dropdown menu.
None
When the Queue Count Evaluation Type is None, the number-based evaluation is disabled.
Example of the None option for count-based evaluation.
Fixed
With the Fixed option, monitoring is based on "fixed" numbers.
Example of the Fixed option for count-based evaluation.
Percentage
With the Percent option, monitoring is based on quota.
Example of the Percent option for count-based evaluation.
Comes First
With the Comes First option, you can set thresholds for Fixed and Percent and both options will be monitored.
Example of the Comes First option for count-based evaluation.
Delivery Count Monitoring
Info
Availability: Delivery Count monitoring is available for both Queues and Topic Subscriptions. Topic Subscriptions got it in version 7.2.0 and Queues in version 7.3.0. Configure it in the Delivery Count panel of the Edit modal.
Nodinite provides fine-grained control over message delivery attempts, enabling you to detect and alert on problematic messages before they reach Azure Service Bus's automatic dead-lettering threshold.
What is Delivery Count?
Every message in Azure Service Bus tracks how many times it has been delivered to consumers. When a message cannot be processed successfully and is abandoned, the delivery count increments. Once the maximum delivery count configured in Azure is reached, the message is automatically moved to the dead-letter queue. The Edit modal shows this Azure value as the Delivery Attempt Limit.
The Delivery Count panel with Fixed evaluation, Warning at 1 and Error at 11. The Delivery Attempt Limit: 10 box reads "After 10 retries, messages are Dead-lettered. This is a property of this specific Topic Subscription."
Example Scenario
- Azure Service Bus resource configured with a delivery attempt limit of 10
- Message fails processing and is abandoned 5 times (Delivery Count = 5)
- Nodinite can alert at delivery count 5 (Warning) and 8 (Error)
- This gives your team time to investigate before the message reaches 10 and gets dead-lettered
Why Monitor Delivery Count?
✅ Proactive Problem Detection - Catch failing messages early, before they become dead letters
✅ Fine-Grained Alerting - Set multiple thresholds (e.g., Warning at 50%, Error at 80% of the delivery attempt limit)
✅ Reduced Downtime - Identify and fix message processing issues before they cascade
✅ Better Visibility - Understand which messages are struggling to process
✅ Compliance & Auditing - Track message retry patterns for troubleshooting and governance
Delivery Count Evaluation Types
The Evaluation Type dropdown in the Delivery Count panel ("Enable or disable delivery count monitoring.") has two modes:
Fixed (Absolute Count)
Monitor based on absolute delivery count values. This gives you precise control regardless of the delivery attempt limit configured in Azure.
Fixed evaluation with Warning at 5 attempts and Error at 8 attempts. This screenshot is from an earlier version, where the Azure value was labeled Max Delivery Count.
When to Use Fixed
- You want consistent thresholds across all queues/subscriptions
- You have specific business rules about retry attempts
- You want alerts at specific retry counts (e.g., always alert at 3 retries)
Example Configuration
- ⚠️ Warning: ≥ 5 (Alert when a message has been delivered 5 or more times)
- ❌ Error: ≥ 8 (Alert when a message has been delivered 8 or more times)
None (Disabled)
Delivery count monitoring is disabled. This is the setting shown in the bottom-part screenshot of the Queue Edit modal above. Use this when:
- You only want to monitor queue depth and message age
- Your processing is idempotent and retries are expected
- Dead-letter monitoring alone is sufficient for your needs
Recommended Threshold Strategies
Nodinite recommends setting delivery count thresholds relative to the Delivery Attempt Limit (the Azure Service Bus MaxDeliveryCount property) to provide early warning:
| MaxDeliveryCount | Recommended Warning | Recommended Error | Rationale |
|---|---|---|---|
| 10 | >= 5 (50%) | >= 8 (80%) | Early detection with time to react |
| 20 | >= 10 (50%) | >= 16 (80%) | Balanced approach for high-retry scenarios |
| 5 | >= 3 (60%) | >= 4 (80%) | Quick alerting for low-retry configurations |
| Custom | >= 50-70% of Max | >= 80-90% of Max | Adapt to your specific tolerance |
Best Practices
- ✅ Set Warning at 50-70% of MaxDeliveryCount to catch issues early
- ✅ Set Error at 80-90% of MaxDeliveryCount for critical alerts
- ✅ Review the Delivery Attempt Limit value displayed in Nodinite to calculate appropriate thresholds
- ✅ Use delivery count monitoring alongside timespan and queue depth thresholds for comprehensive monitoring
- ⚠️ Avoid setting thresholds too low (< 30% of Max) to prevent false alarms from transient failures
How It Works
- Azure Service Bus increments the message's DeliveryCount property each time it's delivered and abandoned
- The Nodinite Message Queueing Monitoring Agent polls active messages and reads their delivery count properties
- Nodinite compares the delivery count of the oldest message against your configured thresholds
- When a threshold is breached, Nodinite raises a Warning or Error alert
- Operators can use List Active Messages to identify and inspect problematic messages
Configuring Delivery Count Thresholds
Configure delivery count monitoring from two locations:
- Resource Level: Use the Edit thresholds action from the Resources list for a specific Queue or Topic Subscription
- Global Level: Configure defaults using Remote Configuration for all resources
Configuration Fields
| Field | Description | Example |
|---|---|---|
| Evaluation Type | Select Fixed or None | Fixed |
| ⚠️ Warning | Delivery count that triggers a Warning alert | ≥ 5 |
| ❌ Error | Delivery count that triggers an Error alert | ≥ 8 |
| Delivery Attempt Limit | Read-only display of the delivery attempt limit configured in Azure, for reference | 10 |
"Set thresholds for message delivery count. Alerts trigger when the oldest message's delivery count exceeds these values."
Viewing Delivery Count in Messages
When you List Active Messages, the Delivery Count is displayed as a property for each message:
Delivery Count property shown in message details, matching Azure Portal's display.
This helps you:
- Identify which specific messages are failing
- Analyze retry patterns across your message workload
- Troubleshoot by inspecting message content and properties
- Take action - repair, resubmit, or move to dead-letter manually
Auto-forwarding
The Auto-forwarding panel holds the Auto-forwarding evaluation dropdown. It decides the state of a Queue or Topic Subscription with Forward to set when active messages remain on it. The panel describes it as: "Controls how an auto-forwarding queue is evaluated when active messages remain. Messages should drain to the forwarding target, so any that linger may indicate the target is unavailable. A quota, dead-letter, or configuration Error still takes precedence." (For a Topic Subscription, the text says "auto-forwarding topic subscription".)
The dropdown has four options:
- Use configured thresholds - Evaluate the entity using the Allowed Timespan and Message Count thresholds, like any other Queue or Topic Subscription.
- ✅ Always OK - Keep the state OK even when active messages remain.
- ⚠️ Raise Warning - Set the state to Warning when active messages remain.
- ❌ Raise Error - Set the state to Error when active messages remain.
When the Resource doesn't override it, the Auto-forwarding evaluation (default) from Remote Configuration applies. For the full picture, with monitoring examples and the Remote Configuration settings, see Forward To for Queues and Topic Subscriptions.
Acknowledge Dead-Letters
The Acknowledge Dead-Letters panel lets you accept the dead-letter messages that already exist, so they stop driving the Resource to Error:
- Acknowledge dead-letters before - A local date and time (e.g.
2025-11-11 15:45:00). "Dead-letter messages before this timestamp report Warning instead of Error. New messages after this date will still trigger Error alerts. Leave blank to treat all dead-letter messages as Errors." - Acknowledge dead-letters up until now - Acknowledge every dead-letter message up to the current time.
The Dead-letter messages acknowledged field in the Resource details at the top of the Edit modal shows whether dead-letters are acknowledged. You can also acknowledge dead-letters directly from the Actions menu; see Acknowledge Dead Letter Messages.
Next Steps
- Back to Actions Overview
- Monitoring Azure Service Bus Queue
- Managing Azure Service Bus Queues
- Monitoring Azure Service Bus Topics
- Managing Azure Service Bus Topics
- Monitoring Azure Service Bus Topic Subscriptions
- Managing Azure Service Bus Topic Subscriptions
Related Topics
- Details – View essential information about the selected Service Bus Queue.
- Acknowledge Dead Letter Messages – Acknowledge dead-letter messages older than now to change the status from Error to Warning.
- Forward To for Queues and Topic Subscriptions – Monitor Queues and Topic Subscriptions with Forward To set.
- Enable – Enable a Service Bus Queue that is currently disabled.
- Disable – Disable a Service Bus Queue that is currently enabled.
- Resubmit and Delete All Dead Letter Messages – Resubmit and delete all dead letter messages in the queue.
- List Active Messages – View all active messages in the queue.
- List Dead Letter Messages – View all dead letter messages in the queue.
- List Scheduled Messages – View all scheduled messages in the queue.
- Purge Messages (Active) – Purge all active messages from the queue.
- Purge Dead Letter – Purge all dead letter messages from the queue.