Why Notifications Fail in Azure Notification Hub and How to Fix Them

Hi @Do Huy Hung ,

Thank you for submitting your question on Microsoft Q&A.

When Web Push notifications don’t arrive through Azure Notification Hubs (ANH)—even though they work fine when you send them directly using the web-push library—it usually comes down to just two issues:

1. The hub’s Web Push (VAPID) credentials aren’t set up correctly.

Either the VAPID keys in ANH don’t match the ones your website uses, or the “subject” value is missing or incorrect. If these don’t line up exactly, ANH can’t send the notification.

2. The message isn’t matching any registrations.

If your targeting (tags, audiences) doesn’t match any devices, ANH accepts the send but has nowhere to deliver it. In other cases, the browser’s push service receives the message but rejects it with a vague “unknown error.”

Here’s a simple checklist to help you fix and confirm everything:

Verify that the VAPID public key, private key, and subject in Notification Hubs match what your app uses.

Make sure your service worker subscribes using the same public key.

Confirm that your device/browser registration appears inside ANH.

Check that the tags or audience you’re sending to actually exist on that registration.

Send a test notification without any targeting (broadcast) to rule out audience issues.

Test the same payload with and without encryption using the web-push library to compare behavior.

These steps should help you narrow down the exact issue and get Web Push working reliably through Notification Hubs

1. Confirm VAPID is set on the Notification Hub (and matches your site)

ANH must have the same VAPID keypair your site uses. In the portal:

Notification Hub > Settings > Browser (Web Push)

• Subject: mailto:you@domain (or an HTTPS origin)

• VAPID Public Key

• VAPID Private Key

• Save

This is required for ANH to authenticate when talking to the browser’s push service (FCM, WNS for Edge, Firefox Push). If these aren’t set or don’t match your site delivery will fail even though your direct web-push calls succeed.

Docs: Send browser (web push) notifications with Azure Notification Hubs – credentials section, including portal and REST options.

2. Verify your installation shape

For browser push, your installation should look exactly like:

{
  "installationId": "<your id>",
  "platform": "browser",
  "tags": ["<your tags>"],
  "pushChannel": {
    "endpoint": "<subscription.endpoint>",
    "p256dh": "<subscription.keys.p256dh>",
    "auth": "<subscription.keys.auth>"
  }
}

That matches what you posted (good). This is the format ANH expects for browser subscriptions.

3. Make sure your tag expression actually targets the installation

Your sendByTagExpression(tagExpression, payload) will enqueue a send even if no registration matches; in that case you’ll see state: "Enqueued" with successCount: 0, failureCount: 0, and empty results—just like your first outcome. Try these quick checks:

• Send to a simple tag you know is on the installation, e.g. "development_all".
• Send to one tag only (no complex expressions) to eliminate syntax issues.
• Confirm tags on the installation by reading it back (Installations API) and verifying the list matches what you’re sending. ANH’s “debug/test sends” and browser push flow are covered here.

For general troubleshooting patterns when notifications are “enqueued” but don’t arrive, Microsoft’s Diagnose dropped notifications guide is useful.

4. Run a direct send to the subscription (bypasses tags)

To isolate whether this is a targeting vs. delivery issue, do a direct send to one subscription endpoint using ANH’s Direct Send with ServiceBusNotification-Format: browser:

HTTP (REST) example (adapt it to your TS client if convenient):

POST https://{namespace}.servicebus.windows.net/{hub}/messages?api-version=2020-06&direct
Authorization: SharedAccessSignature sr=...
Content-Type: application/json
ServiceBusNotification-Format: browser
ServiceBusNotification-DeviceHandle: https://wns2-...notify.windows.com/w/?token=...   // subscription.endpoint
P256DH: <subscription.keys.p256dh>
Auth: <subscription.keys.auth>

{"title":"Hello","body":"Notification Hub test"}

Community reports show this “created/enqueued” response while delivery fails if browser push isn’t fully wired-up in the hub or SDK—so this is a good litmus test.

5. Understand the WNS endpoint you’re seeing (Edge/Windows)

You mentioned endpoints like https://wns2-sg2p.notify.windows.com/w/?token=.... That’s valid for Web Push on Microsoft Edge / Windows Edge uses the Windows Push Notification Service (WNS) as its web push provider. WNS has its own reliability/availability characteristics (there have been reported outages), so if everything else checks out, a transient WNS issue can manifest as “unknown error.”

If you test the same subscription in Chrome (FCM endpoint) or Firefox (Mozilla endpoint) and it works via ANH, that further points to a WNS-specific path.

6. Check your Service Worker and payload

Make sure your SW is active and shows the notification:

self.addEventListener("push", event => {
  const data = event.data?.json?.() ?? {};
  event.waitUntil(
    self.registration.showNotification(data.title || "Title", {
      body: data.body || "Message",
      icon: "/icon.png",
      data: data
    })
  );
});

This pattern is consistent with the docs/blog examples of how browser push payloads are consumed. If your payload isn’t JSON (or the SW throws), the toast won’t show even if the push arrives.

7. Use ANH diagnostics and known caveats

• Diagnose dropped notifications: Work through the four stages (client, backend, ANH, PNS) to pinpoint where the drop occurs.
• SDK status: There have been threads noting “unknown error” for browser push while direct web-push succeeds; when the SDK path is problematic, the REST direct send approach above is a solid workaround until an SDK update resolves the edge cases.

8. A minimal working checklist

1. In the hub, set Browser (Web Push) credentials with the same VAPID public/private keys you use in web-push. Also set a valid subject (e.g., mailto:admin@yourdomain).
2. Confirm your installation (platform: "browser") includes endpoint, p256dh, and auth from the browser’s PushSubscription.
3. Send to a single tag that is present on the installation; if you still see successCount: 0, try the direct send REST call with ServiceBusNotification-Format: browser, P256DH, Auth, and the subscription endpoint.
4. Test on another browser (Chrome/Firefox) to see if WNS‑specific delivery is the issue. Reference WNS overview/outage notes if Edge/Windows path is flaky.
5. Verify your Service Worker correctly parses and shows the notification.
6. If delivery still fails, follow the dropped notifications diagnostics to isolate misconfiguration vs. push service rejection.

Reference:

https://learn.microsoft.com/en-us/azure/notification-hubs/browser-push

https://learn.microsoft.com/en-us/azure/notification-hubs/notification-hubs-push-notification-fixer

https://stackoverflow.com/questions/78893735/direct-web-push-gives-error-when-used-from-notification-hub

https://learn.microsoft.com/en-us/windows/apps/develop/notifications/push-notifications/wns-overview

Kindly let us know if the above comment helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.