Edit Thresholds
Tip
Edit the Monitoring thresholds for the selected Service Bus Queue or 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 Monitoring - New in 7.2.0 - Monitor message delivery attempt counts to detect problematic messages (Coming Soon for Queues).
Click the Edit thresholds menu item in the Actions button on the selected queue to open the Edit Service Bus Queue Monitoring Thresholds modal.
Example of the 'Edit thresholds' menu item in the Actions button menu.
Displays the modal for editing Service Bus Queue Monitoring thresholds.
If you see the following alert; it means that this queue is using global thresholds. When you click on the Save button you will start to use specific thresholds instead.
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 TimeSpan | Timespan | 00:05:00 (5 minutes) | The age of the first message on the queue to trigger Warning alert | |
| 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 Count | integer | >=0 | The number of messages to go above on the queue to trigger Warning alert | |
| Error Count | integer | >=0 | The number of messages to go above on the queue to trigger Error alert | |
| Warning Limit % | integer | 1-100 | Set the threshold quota value in percentage (1-100) to trigger Warning alert | |
| 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:
- Topic Subscriptions: Available in version 7.2.0
- Queues: Coming in a future release of the Message Queueing Monitoring Agent
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 Max Delivery Count (configured in Azure) is reached, the message is automatically moved to the dead-letter queue.
The Max Delivery Count configured in Azure Service Bus is displayed for reference when setting thresholds.
Example Scenario:
- Azure Service Bus resource configured with Max Delivery Count: 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 MaxDeliveryCount)
✅ 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
You can choose between two evaluation modes:
Fixed (Absolute Count)
Monitor based on absolute delivery count values. This gives you precise control regardless of Azure's MaxDeliveryCount setting.
Example: Fixed evaluation with Warning at 5 attempts, Error at 8 attempts.
When to use:
- 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 Threshold: >= 5 (Alert when any message has been delivered 5 or more times)
- Error Threshold: >= 8 (Alert when any message has been delivered 8 or more times)
None (Disabled)
Delivery count monitoring is disabled. 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 Azure's MaxDeliveryCount 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 Max Delivery Count 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 highest delivery count found 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 specific queues/subscriptions
- Global Level: Configure defaults using Remote Configuration for all resources
Configure Delivery Count monitoring thresholds with Warning and Error levels.
Configuration Fields:
| Field | Description | Example |
|---|---|---|
| Evaluation Type | Select Fixed or None | Fixed |
| Max Delivery Count | Read-only display of Azure's configured maximum (for reference) | 10 |
| Warning Threshold | Delivery count to trigger Warning alert | >= 5 |
| Error Threshold | Delivery count to trigger Error alert | >= 8 |
Setting Help Text:
"Set thresholds for message delivery count. Alerts trigger when the oldest message's delivery count reaches these values. Recommended: Warning at 50-70% of MaxDeliveryCount, Error at 80-90%."
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
Next Step
Related Topics
- Details – View essential information about the selected Service Bus Queue.
- 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.