Azure Event Grid MQTT Broker: Successful publishes and subscriptions but zero delivered messages

Question

Azure Event Grid MQTT Broker: Successful publishes and subscriptions but zero delivered messages

Marvin Schwander 0

Hello,

I am currently facing an issue with Azure Event Grid MQTT broker where messages are successfully published and subscriptions are accepted, but no messages are ever delivered to subscribers.

Environment / Setup

Azure Event Grid Namespace with MQTT broker enabled
Authentication via Thumbprint match
Two MQTT clients:
- MQTT-CONTROL-PROD → Publisher
  - MQTT-LOCAL1-PROD → Subscriber
  - Tested using MQTTX
  - Both clients can successfully connect

Client Configuration

Subscriber

Authentication Name: MQTT-LOCAL1-PROD
Certificate CN: MQTT-LOCAL1-PROD
Validation: Thumbprint Match
Assigned to Client Group: test-subscribers

Publisher

Authentication Name: MQTT-CONTROL-PROD
Assigned to Client Group: test-publishers

Client Groups

test-subscribers:
authenticationName = "MQTT-LOCAL1-PROD"

test-publishers:
authenticationName = "MQTT-CONTROL-PROD"

Topic Space

Topic Space Templates:

test/{*}
test/#
test/+
mqttx/test

Permission Bindings

test-publishers → Topic Space test → Role: Publisher
test-subscribers → Topic Space test → Role: Subscriber

Observed Behavior

Publishing

Messages are successfully published (no errors)
Example topics:

test/1
test/2
...
test/10

Subscribing

Subscriber subscribes to exact same topics
No authorization errors (previously fixed)
Subscriptions are counted in metrics

Metrics (Azure Portal)

✅ Successful Published Messages (sum): ~30 (other devices connected and are publishing, but without any successful subscription
✅ Successful Subscription Operations (sum): ~7
❌ Successful Delivered Messages: 0
✅ No significant failed publishes
✅ Connections stable

{A0C48FDE-8295-4A0A-BBE9-447490BF10A3}

Result

Despite:

Valid topic match
Successful subscriptions
No authorization errors
Active connections

👉 No messages are received by the subscriber

Expected Behavior

Messages published to topics like:

test/1

should be delivered to subscribers subscribed to:

test/1

Troubleshooting Steps Already Taken

Verified certificate configuration (Thumbprint matches correctly)
Tested with different topic filters
Reconnected clients multiple times
Confirmed subscriptions via metrics
Ensured correct Client Group mapping
Used simplified Topic Space definitions
Tested multiple publish events (40+ messages)

Key Question

Why are messages not delivered even though:

subscriptions are successful
- topics match exactly
  - permissions are correctly assigned
  Is there any additional routing, matching, or internal behavior in Event Grid MQTT that could prevent delivery in this scenario?

Additional Observation

It seems that:

Publish and Subscribe work independently
But no delivery linkage exists between them

Is this expected behavior, or could this indicate:

a misconfiguration that is not obvious
or a potential issue with the Event Grid MQTT service / namespace state?

Request

Could you please help identify:

Whether this setup is missing any required configuration
If this behavior is expected under certain conditions
Or if this might be a known issue/limitation/bugHello, I am currently facing an issue with Azure Event Grid MQTT broker where messages are successfully published and subscriptions are accepted, but no messages are ever delivered to subscribers.

Pravallika KV 16,365 Reputation points Microsoft External Staff Moderator

2026-05-29T10:25:35.6066667+00:00
Hi @Marvin Schwander ,

Since you still see zero deliveries, here are a few things to double-check along with some next steps:

Validate your Topic Space definitions and wildcard syntax

Even though you’ve defined “test/{*}”, “test/#” and “test/+”, the broker only uses the MQTT-style wildcards (+ and #).

Make sure your topic space really includes a pattern like test/# (which will match test/1, test/2/child, etc.) or exactly test/+ (which matches only one level under test/).

If you’re using a custom template syntax ({*}), swap it out for the MQTT wildcard characters in the portal or ARM configuration.

Confirm Quality of Service (QoS) and acknowledgments

If you subscribe at QoS 0, messages are fire-and-forget. Try QoS 1 on both publisher and subscriber so the broker tracks AND retries delivery until the client ack’s.

Watch the “Successful Acknowledged Events” metric – if it never increments, the broker thinks your subscriber isn’t acknowledging receipts.

Check session and expiry settings

By default, sessions may not persist after disconnect. If the client disconnects between your publishes and subscribes, it will miss messages.

Verify your “Clean Session” (MQTT 3) or “Clean Start” (MQTT 5) flag is set to false if you want durable subscriptions.

Also look at the Message Expiry Interval (MQTT 5) in case your messages are expiring before the subscriber connects or has a chance to ack.

Review access-control bindings

You’ve got test-publishers → Publisher and test-subscribers → Subscriber on the “test” space, which looks right. Just double-check in the portal that no stray default client group (like $all) is overriding your custom groups.

If your client group isn’t explicitly bound to the topic space you expect, the broker will allow connection/subscription but silently drop deliveries.

Turn on diagnostic logging and capture broker logs

Enable Event Grid diagnostics for your namespace (under Monitoring > Diagnostic settings) and send to Log Analytics or Storage.

Review MQTT Broker logs to see if delivery attempts are being made and, if so, what error codes (if any) are returned.

Rule out limits and filters • Verify you’re not hitting message-size limits or per-client rate limits. • If you have any routing filters (even empty default filters), make sure they aren’t inadvertently filtering out your messages.

If after checking the above you still see zero deliveries, please share:

Your exact topic-space definitions as configured in the Azure portal or via ARM/bicep

The MQTT version (3.1.1 vs. 5) and QoS levels you’re using for both publish and subscribe

Whether you’re using persistent sessions (Clean Session = false)

Any relevant snippets from the diagnostic or broker logs around the time you attempt delivery

That info will help pinpoint if it’s a configuration quirk or a potential service issue. Hope this helps!

References

MQTT broker troubleshooting - client can’t publish/receive

Configuring topic spaces

Access control with client groups & permission bindings

MQTT broker overview & key concepts (wildcards, QoS, sessions)

Monitoring Event Grid delivery metrics & diagnostics

Marvin Schwander 0

Hi Pravallika,

Thank you for your quick reply. Now to my answers:

For the first part in my test topic space, I removed {*}, just keeping test/+ and test/#.
I use on MQTTX (I don't know how it will be with the connected devices then) QoS 1 in both publish and subscribe, and clean session = false. Then interesting part is the successful aknowledged events, I am not sure how I acknowledge it via MQTTX or any other client that is subscribed, I don't see an option to put this in or send something, there is only a last will testament option, which in my eyes will be sent when client disconnects.
As mentioned before, I am using MQTT 3.1.1, so clean session is false on MQTTX, don't know how I can then set this in my function app to work.
I have it like this and we are only looking at test topic space, the rest is also not working:

But even if, $all should still work or in my case now debug-all with query true. This is not the problem.

Diagnostic logging is switched on, but I can't find any useful KQL commands to check for mistakes.

Can't find any filters or limits that are set, I am sending such a small JSON as a test:

   {
     "name": "John Doe",
     "age": 30,
     "isStudent": false,
     "courses": [
       "Math",
       "Science",
       "History"
     ]
   }

My clientGroups

        {
            "type": "Microsoft.EventGrid/namespaces/clientGroups",
            "apiVersion": "2025-07-15-preview",
            "name": "[concat(parameters('namespaces_ekz_prod_01_appl_batterie_ortsnetz_evgns_name'), '/$all')]",
            "dependsOn": [
                "[resourceId('Microsoft.EventGrid/namespaces', parameters('namespaces_ekz_prod_01_appl_batterie_ortsnetz_evgns_name'))]"
            ],
            "properties": {
                "description": "Default group with all clients.",
                "query": "true"
            }
        },
        {
            "type": "Microsoft.EventGrid/namespaces/clientGroups",
            "apiVersion": "2025-07-15-preview",
            "name": "[concat(parameters('namespaces_ekz_prod_01_appl_batterie_ortsnetz_evgns_name'), '/debug-all')]",
            "dependsOn": [
                "[resourceId('Microsoft.EventGrid/namespaces', parameters('namespaces_ekz_prod_01_appl_batterie_ortsnetz_evgns_name'))]"
            ],
            "properties": {
                "description": "debugger client group",
                "query": "true"
            }
        },
        {
            "type": "Microsoft.EventGrid/namespaces/clientGroups",
            "apiVersion": "2025-07-15-preview",
            "name": "[concat(parameters('namespaces_ekz_prod_01_appl_batterie_ortsnetz_evgns_name'), '/test-publishers')]",
            "dependsOn": [
                "[resourceId('Microsoft.EventGrid/namespaces', parameters('namespaces_ekz_prod_01_appl_batterie_ortsnetz_evgns_name'))]"
            ],
            "properties": {
                "description": "Publishers test\n",
                "query": "authenticationName = 'MQTT-CONTROL-PROD'"
            }
        },
        {
            "type": "Microsoft.EventGrid/namespaces/clientGroups",
            "apiVersion": "2025-07-15-preview",
            "name": "[concat(parameters('namespaces_ekz_prod_01_appl_batterie_ortsnetz_evgns_name'), '/test-subscribers')]",
            "dependsOn": [
                "[resourceId('Microsoft.EventGrid/namespaces', parameters('namespaces_ekz_prod_01_appl_batterie_ortsnetz_evgns_name'))]"
            ],
            "properties": {
                "description": "TESTER SETUP",
                "query": "\nauthenticationName = 'MQTT-LOCAL1-PROD'"
            }
        },


My Permission Bindings:


```json
 {
            "type": "Microsoft.EventGrid/namespaces/permissionBindings",
            "apiVersion": "2025-07-15-preview",
            "name": "[concat(parameters('namespaces_ekz_prod_01_appl_batterie_ortsnetz_evgns_name'), '/allpub-pixii')]",
            "dependsOn": [
                "[resourceId('Microsoft.EventGrid/namespaces', parameters('namespaces_ekz_prod_01_appl_batterie_ortsnetz_evgns_name'))]"
            ],
            "properties": {
                "topicSpaceName": "pixii",
                "permission": "Publisher",
                "clientGroupName": "debug-all"
            }
        },
        {
            "type": "Microsoft.EventGrid/namespaces/permissionBindings",
            "apiVersion": "2025-07-15-preview",
            "name": "[concat(parameters('namespaces_ekz_prod_01_appl_batterie_ortsnetz_evgns_name'), '/allpub-swisbox')]",
            "dependsOn": [
                "[resourceId('Microsoft.EventGrid/namespaces', parameters('namespaces_ekz_prod_01_appl_batterie_ortsnetz_evgns_name'))]"
            ],
            "properties": {
                "topicSpaceName": "swisbox",
                "permission": "Publisher",
                "clientGroupName": "debug-all"
            }
        },
        {
            "type": "Microsoft.EventGrid/namespaces/permissionBindings",
            "apiVersion": "2025-07-15-preview",
            "name": "[concat(parameters('namespaces_ekz_prod_01_appl_batterie_ortsnetz_evgns_name'), '/allsub-pixii')]",
            "dependsOn": [
                "[resourceId('Microsoft.EventGrid/namespaces', parameters('namespaces_ekz_prod_01_appl_batterie_ortsnetz_evgns_name'))]"
            ],
            "properties": {
                "topicSpaceName": "pixii",
                "permission": "Subscriber",
                "clientGroupName": "debug-all"
            }
        },
        {
            "type": "Microsoft.EventGrid/namespaces/permissionBindings",
            "apiVersion": "2025-07-15-preview",
            "name": "[concat(parameters('namespaces_ekz_prod_01_appl_batterie_ortsnetz_evgns_name'), '/allsub-swisbox')]",
            "dependsOn": [
                "[resourceId('Microsoft.EventGrid/namespaces', parameters('namespaces_ekz_prod_01_appl_batterie_ortsnetz_evgns_name'))]"
            ],
            "properties": {
                "topicSpaceName": "swisbox",
                "permission": "Subscriber",
                "clientGroupName": "debug-all"
            }
        },
        {
            "type": "Microsoft.EventGrid/namespaces/permissionBindings",
            "apiVersion": "2025-07-15-preview",
            "name": "[concat(parameters('namespaces_ekz_prod_01_appl_batterie_ortsnetz_evgns_name'), '/pub-test')]",
            "dependsOn": [
                "[resourceId('Microsoft.EventGrid/namespaces', parameters('namespaces_ekz_prod_01_appl_batterie_ortsnetz_evgns_name'))]"
            ],
            "properties": {
                "topicSpaceName": "test",
                "permission": "Publisher",
                "clientGroupName": "test-publishers"
            }
        },
        {
            "type": "Microsoft.EventGrid/namespaces/permissionBindings",
            "apiVersion": "2025-07-15-preview",
            "name": "[concat(parameters('namespaces_ekz_prod_01_appl_batterie_ortsnetz_evgns_name'), '/sub-test')]",
            "dependsOn": [
                "[resourceId('Microsoft.EventGrid/namespaces', parameters('namespaces_ekz_prod_01_appl_batterie_ortsnetz_evgns_name'))]"
            ],
            "properties": {
                "topicSpaceName": "test",
                "permission": "Subscriber",
                "clientGroupName": "test-subscribers"
            }
        },

This is the last test I have done via subscribing on test/1 and test/abc, no acknowledged event or anything. I heard taht after some snon-successful subscription operations, clients stop to susbcribe, is that correct?

{4F27B827-A16F-483A-AEF5-108FCFE87DBC}

Pravallika KV 16,365 Reputation points Microsoft External Staff Moderator

2026-06-02T00:02:28.03+00:00

@Marvin Schwander , I will check and update you.

2 answers

Your answer

Pravallika KV 16,365 Reputation points Microsoft External Staff Moderator

2026-06-02T00:02:28.03+00:00

@Marvin Schwander , I will check and update you.

Answer 1

Hello @Marvin Schwander ,

Welcome to this Azure community forum.

You have an issue with the Azure Eventgrid Namespace MQTT broker support.

Although the broker follows the plain MQTT protocol requirements and the configuration is very flexible, debugging message reception can be a thing.

I wrote a blog post in the past showing how to get a working environment.

I would suggest trying of-the-shelf clients first, like MQTTX for sending and receiving messages.

I can also recommend using MQTT Explorer for testing reception in general.

One special thing is the client group assignment. Check this blog post showing how we can test the relationship between clients, client groups, topic spaces, and topics in one go.

Last but not least, I would prevent overlap in topics during testing at first:

aaa/#
aaa/+

These two overlap; I'm not sure what happens.

Is a message published on topic 'aaa/bb' ending up on both topics?
Do subscribers receive the same message twice?

Keep it simple and have a working connection first before you experiment with more elaborate solutions.

If this answer helps you, marking it as the accepted answer is appreciated. All community members with similar questions will benefit by doing so. Your contribution is highly appreciated.

Marvin Schwander 0 Reputation points

2026-06-01T15:58:47.03+00:00

Thank you for trying to help me, but once again, the published messages can't be subscribed to. I can clearly see that published messages are successful (according to Azure Eventgrid) and Eventgrid allows me to subscribe to these topics, but they just don't show up. That permission bindings exist is clear, but I created them several times, with $all and as well with permission bindings for specific clients, nothing works. It can not be a problem with authorized, as I see the connections and that they are allowed to subscribe, because when choosing a topic to subscribe to and it exists, this is accepted, otherwise I get the message that it is not authorized to do so.

Answer 2

The described behavior indicates that publish and subscribe operations are succeeding, but the broker isn’t matching those operations for delivery. In Azure Event Grid MQTT broker this is almost always caused by access control or topic-space configuration, not by an additional routing step.

Based on the documented troubleshooting guidance, the following areas must be verified in this order:

Client group membership and permissions
- Ensure the subscriber client (MQTT-LOCAL1-PROD) is actually in the test-subscribers client group and the publisher (MQTT-CONTROL-PROD) is in test-publishers.
- Confirm that the permission bindings grant publish permission for test-publishers and subscribe permission for test-subscribers on the same topic space. If the client group or topic space names differ even slightly from what’s used in bindings, messages won’t be delivered even though publishes and subscribes succeed.
- If the client disconnects when publishing, or if the topic doesn’t exist in the configured topic space, the broker can drop messages. Verify that the topics test/1, test/2, … are actually covered by the topic space bound to test-publishers and test-subscribers.
Topic space coverage of subscriptions
- The broker only delivers messages when the subscribed topics are included in the topic space to which the client has subscribe access. Ensure that the subscription filters (for example test/1) are within the topic templates configured in the test topic space.
- If the subscriber is using patterns like test/# or test/+, verify that these patterns are allowed by the topic space configuration and not filtered out.
Message size and expiry
- If a maximum message size is configured, messages larger than this limit can be rejected for delivery while still counting as successful publishes. Verify that the payload size is within the configured limits.
- If a message expiry interval is configured and is too short relative to the subscriber’s connectivity pattern, messages can expire before being delivered.
QoS and acknowledgments
- Use QoS 1 to have the service guarantee at-least-once delivery.
- Ensure the subscriber acknowledges messages. If acknowledgments aren’t received, the service stops sending messages to that client after 16 unacknowledged messages, which results in zero delivered messages despite successful publishes.
Routing to endpoints (if applicable)
- If MQTT messages are also being routed to Event Grid topics or other endpoints, verify that the Data Sender role is enabled on the routing topic and that CloudEvent schema v1.0 is used. Misconfigured routing can cause messages not to appear at downstream endpoints even though they are published successfully.
Namespace and client lifecycle
- Confirm the namespace is healthy and available in the region.
- Configure MQTT client life-cycle events to capture disconnect reasons and verify that clients remain connected during publish/subscribe operations.

If, after validating:

client group membership,
permission bindings,
topic space coverage,
message size/expiry,
QoS and acknowledgments,

there are still zero “Successful Delivered Messages” while “Successful Published Messages” and “Successful Subscription Operations” continue to increase, this indicates a service-side issue. In that case, capture metrics and logs and open a support ticket so the Event Grid team can inspect the namespace state.

References:

Share via

Azure Event Grid MQTT Broker: Successful publishes and subscriptions but zero delivered messages

Environment / Setup

Client Configuration

Subscriber

Publisher

Client Groups

Topic Space

Permission Bindings

Observed Behavior

Publishing

Subscribing

Metrics (Azure Portal)

Result

Expected Behavior

Troubleshooting Steps Already Taken

Key Question

Additional Observation

Request

2 answers

Your answer