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

Marvin Schwander 0 Reputation points
2026-05-29T10:13:14.2433333+00:00

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:

  1. Whether this setup is missing any required configuration
  2. If this behavior is expected under certain conditions
  3. 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.
Azure Event Grid
Azure Event Grid

An Azure event routing service designed for high availability, consistent performance, and dynamic scale.

5 answers

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-05-29T10:13:44.3266667+00:00

    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:

    1. 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.
    2. 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.
    3. 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.
    4. 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.
    5. 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.
    6. 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:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

  2. Sander van de Velde | MVP 37,081 Reputation points MVP
    2026-05-30T09:13:55.2533333+00:00

    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.

    Was this answer helpful?

  3. Pravallika KV 18,850 Reputation points Microsoft External Staff Moderator
    2026-06-04T00:29:05.7+00:00

    Based on what you've shared, QoS acknowledgements are unlikely to be the root cause. In MQTTX, PUBACK handling for QoS 1 is automatic, so there is no manual acknowledgement action required from the subscriber. If Event Grid is already reporting successful publish operations, then the broker is correctly accepting and processing the published messages.

    The main concern remains that successful subscriptions and successful publishes are being recorded, while successful delivered messages remain at zero. This suggests that the broker is not finding a matching subscriber for message delivery.

    One area worth reviewing is the Topic Space configuration. Azure Event Grid Topic Spaces are authorization constructs and do not always behave the same way as MQTT subscription filters. Using Topic Space templates such as test/+ and test/# may not provide the expected routing behavior.

    As a troubleshooting step, I recommend creating a dedicated test Topic Space with a single explicit topic, for example:

    Topic Space template: test/1

    Publisher permission bound to test/1

    Subscriber permission bound to test/1

    Subscriber subscribes to test/1

    Publisher publishes to test/1

    1. Verify MQTT client authentication configuration, including authentication names and certificate thumbprint matching.
    2. Confirm both publisher and subscriber clients were successfully connected to the Event Grid namespace.
    3. Validate client group membership for both publisher and subscriber clients. Verify permission bindings granted Publisher and Subscriber access to the same topic space. Confirm topic space definitions covered the published and subscribed topics.
    4. Test using simplified topic spaces and explicit topic mappings (for example, test/1) to eliminate any wildcard-related configuration issues.
    5. Validate MQTT QoS 1 settings and persistent session configuration.
    6. Confirm successful MQTT acknowledgments:
      • Publisher received PUBACK responses.
      • Subscriber received SUBACK responses.
    7. Review Azure metrics and verified that:
      • Successful Published Messages were increasing.
      • Successful Subscription Operations were increasing.
      • Successful Delivered Messages remained at zero.
    8. Enable and review diagnostic logs to identify any delivery-related failures.
    9. Verify there were no issues with client configuration, certificates, QoS settings, topic definitions, subscriptions, or permission bindings.
    10. As a final step, please try recreating the Event Grid namespace and redeploying the MQTT resources, including:
      • MQTT Clients
      • Client Groups
      • Topic Spaces
      • Permission Bindings
      • Certificates

    Was this answer helpful?

    0 comments
  4. Schwander Marvin ZTL 0 Reputation points
    2026-06-10T09:24:47.85+00:00

    Hi, thanks for your reply. Problem could be solved by killing the eventgrid and setting it up again from scratch. Very sad to see that such a huge company does not have any better way to solve a problem like this. Was never my mistake, I lost a lot of time because the debugging of the eventgrid broker is just so bad, very disappointed by Microsoft for this.

    Was this answer helpful?

    0 comments
  5. Sina Salam 31,456 Reputation points Volunteer Moderator
    2026-07-27T11:48:13.8666667+00:00

    Hello Marvin Schwander,

    Welcome to the Microsoft Q&A and thank you for posting your questions here.

    I understand that your Azure Event Grid MQTT Broker publishes and subscriptions succeed, but no messages are delivered to subscribers.

    The fact is that:

    1. Subscriber must manually acknowledge MQTT QoS1 deliveries.
    2. Successful Acknowledged Events metric should increase even if deliveries never happen.
    3. Topic Space wildcards affect message routing.

    With careful review of the issue, this is not caused by MQTT client configuration, certificates, QoS settings, topic matching, subscriptions, or permission bindings. The subscriber successfully received SUBACK responses, the publisher successfully received PUBACK responses, and Azure metrics recorded successful publish and subscription operations. However, Successful Delivered Messages remained at zero, indicating a failure within the Event Grid MQTT broker routing path rather than a client-side configuration issue.

    What you can do to fix is to recreate the Event Grid Namespace and redeploy the MQTT resources (Clients, Client Groups, Topic Spaces, Permission Bindings, and Certificates). Base on what you've done, the issue was isolated to the original namespace state rather than the MQTT configuration.

    If the same behaviour occurs in a newly created namespace, the issue should be escalated to Azure Support via your Azure portal or contact priority customer service for backend broker investigation because all documented MQTT configuration checks have already been ok.

    Use the below resource for more reading and steps:

    I hope this is helpful. Please! Do not hesitate to let me know if you have any other questions, steps or clarifications.

    Please do not close the thread by upvoting and accepting the answer if any part of it is helpful.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.