New pricing plans - daily message throughput

The new pricing plans of NServiceBus come with limits on daily message throughput.

What would be the best way of monitoring the daily throughput? Any recommendations?

Auditing + “Search by date” in ServiceInsight?

Given that auditing is enabled for all receive endpoints, would the number of messages passing through the audit queue during a day be “an accurate” metric?


Are you running ServiceControl? If so:

Please exclude any ServiceControl or ServiceControl monitoring endpoints.

  1. Ensure all endpoints have the metrics plugin installed and are connected to the same ServiceControl Monitoring instance.
  2. Go to the monitoring page in ServicePulse and select “15m” on the top right to show data from the last 15 minutes.
  3. Wait for a busy period of at least 15 minutes. The system should be busy for the whole 15 minute window.
  4. Sum up all of the “Throughput” values. This will provide a measurement of throughput in messages per second for the whole system.
  5. Multiply this number by 86,400 (24 hours * 60 minutes * 60 seconds) to estimate throughput per day.

If the customer has a lot of endpoints, it may be easier to grab the raw data. To do that, go to the following URL and save the returned json file:


This file will contain a list of logical endpoints and their average throughput over the last 15 minutes.

Customers that are NOT running ServiceControl monitoring

If customers are not running ServiceControl monitoring in their production environment, we count endpoints and measure throughout using transport-specific techniques.

For broker-based transports, we estimate the number of logical endpoints by counting the queues in the broker.

For MSMQ, we still count the queues but we may need to ask additional questions in order to translate those numbers into a count of logical endpoints. E.g. is the customer using a distributor or sender-side distribution?

In both cases, it would be handy to get the full list of queue names (as we can do some processing on them later) but if the customer does not want to provide them then a count is OK.

Each transport also has it’s own way of measuring throughput.

See the documentation for the transport the customer is using:

  • MSMQ
  • SQL
  • RabbitMQ
  • Azure Service Bus (including the .NET Standard version)
  • Azure Storage Queues
  • Amazon SQS

Please feel free to email me for more info:

In general, I think this is a good solution. However, in our future setup, I foresee big bursts of messages at times where it’s hard to be present and monitor it.

We are using Azure Service Bus as transport, where there’s quite good message throughput metrics. Might be possible to look at outgoing messages (I assume this means messages where a processing attempt has been made) for all non-NServiceBus-platform queues? Some messages might fail and be retried later, of course, so it won’t be 100% correct.

Anyways, it would be a nice addition to ServiceControl and ServicePulse to track and present the message throughput per day, the last X days. Just a counter that is. Might submit an improvement issue for this on GitHub.

1 Like

Thanks for the feedback Kato!

I’ll be discussing your suggestion internally.