Azure Event Grid MQTT Broker: Successful Published Messages > 0 but Successful Delivered Messages = 0

The described symptoms match a broker-side routing or delivery issue, not a client misconfiguration, given that:

• MQTT connections succeed.
• Subscriptions are accepted (SUBACK granted).
• Publishes are accepted (PUBACK success).
• MQTT: Successful Published Messages > 0.
• MQTT: Successful Delivered Messages = 0.
• No subscribers receive messages.

From the available guidance, the following checks and diagnostics are supported:

1. Verify publish/subscribe access and topic spaces
   • Confirm that the client groups used by publishers and subscribers are correctly configured and that:
     • The client belongs to the correct client group (if not using $all).
     • The client group has publish or subscribe permissions configured to the correct topic spaces.
   • Ensure that the topics being subscribed to are included in the topic space to which the client has subscribe access.
   • If response topics are used, ensure subscribers are listening on the response topics before publishing on the request topic.
   These checks are explicitly called out for scenarios where clients connect and publish but do not receive messages.
2. Check message size, expiry, and QoS behavior
   • If a maximum message size is configured, ensure published messages meet the size requirements of the subscribing client.
   • Ensure the message expiry interval is appropriate for the connectivity pattern so messages are not expiring before delivery.
   • Use QoS 1 and ensure clients send acknowledgments; if acknowledgments are not received, the service stops sending messages after 16 unacknowledged messages.
3. Inspect MQTT metrics for delivery and throttling issues
   • Review the following metrics on the Event Grid namespace:
     • MQTT.SuccessfulPublishedMessages and MQTT.FailedPublishedMessages to confirm that publishes are succeeding and not being rejected for specific errors.
     • MQTT.SuccessfulDeliveredMessages to confirm that the broker is not reporting any deliveries.
     • MQTT.ThrottlingEnforcements to see if throttling is being enforced.
     • MQTT.RequestCount, MQTT.SuccessfulSubscriptionOperations, and MQTT.FailedSubscriptionOperations to verify that subscription operations are being accepted and not failing for some filters.
     • Mqtt.DroppedSessions and its DropReason dimension to understand why sessions are being dropped (for example, AuthorizationError, SessionOverflow, or session expiry).
4. Use resource logs to identify failed publish or subscription operations
   • Enable and inspect the MQTT broker diagnostic logs for:
     • Failed MQTT published messages (EventGridNamespaceFailedMqttPublishedMessages), which show:
       • topicName, qos, protocol, and resultDescription for failed publishes or deliveries.
     • Failed MQTT subscription operations (EventGridNamespaceFailedMqttSubscriptions), which log each topic filter that fails.
   • Also review common log properties such as operationName, category, resultType, resultSignature, and resultDescription to identify whether the broker is rejecting operations due to quota, authentication, or authorization errors.
5. Check routing to downstream endpoints (if applicable)
   • If MQTT messages are being routed to other endpoints via Event Grid routing:
     • Ensure the Data Sender role is enabled on the routing topic.
     • Confirm that CloudEvent Schema v1.0 is used for routing.
     • Verify that routing filters are not dropping the data.
     • For HTTP publish scenarios, verify that topics are percent-encoded and that the correct namespace is used.
6. Confirm broker health and internal routing via metrics and logs
   • For suspected internal routing issues (publishes accepted but no deliveries and no obvious configuration errors), the supported approach is:
     • Use metrics such as MQTT.SuccessfulDeliveredMessages, Mqtt.SuccessfulPublishLatencyInMilliseconds, and Mqtt.SuccessfulConnectLatencyInMilliseconds to understand whether the broker is processing messages and acknowledgments as expected.
     • Use resource logs to see if there are systematic failures or throttling at publish or subscription time.

If metrics and logs confirm that:

• Publishes are succeeding (MQTT.SuccessfulPublishedMessages increasing, no corresponding MQTT.FailedPublishedMessages with meaningful resultDescription),
• Subscriptions are accepted (MQTT.SuccessfulSubscriptionOperations increasing, minimal MQTT.FailedSubscriptionOperations), and
• MQTT.SuccessfulDeliveredMessages remains at 0 despite active subscribers,

then the behavior is consistent with a broker-side issue rather than configuration. In that case, the next supported step is to collect:

• Relevant metrics snapshots (including Mqtt.DroppedSessions with DropReason),
• Diagnostic log excerpts for failed publishes/subscriptions (including resultSignature and resultDescription),

and open a support case so the Event Grid team can investigate the namespace-specific routing behavior.

References:

• Guide to troubleshoot issues with Azure Event Grid’s MQTT broker feature
• Monitor data reference for Azure Event Grid’s MQTT broker feature
• Publish MQTT messages via HTTP with Azure Event Grid
• Tutorial: Bi-directional MQTT bridge to Azure Event Grid