Azure Notification Hubs

About Azure Notification Hubs

Azure Notification Hubs is a managed Azure push notification service for applications that need to reach mobile or browser users across multiple platform notification systems without building their own device-registration and fan-out layer. App backends send messages to a notification hub, while devices register the handles issued by their platform notification service. The service is most useful when a team needs one backend-facing push layer for multiple platforms, targeted audiences, or large broadcast volumes.

What is Azure Notification Hubs used for?

Azure Notification Hubs is designed for app notifications rather than general event streaming. Typical uses include transactional alerts, service updates, reminders, marketing messages, user-specific notifications, and broadcasts to large device populations. Microsoft documents support for major push platforms and allows a backend to send platform-specific payloads or use templates that adapt messages for different device platforms.

The service can sit behind cloud or on-premises application backends. Devices register their platform notification system handles with a hub, and the backend targets those registrations rather than maintaining a separate push connection for every platform.

How do tags, templates, and targeting work?

Notification Hubs can target a single device, a user, a segment, or a broad audience. Tags let an application associate registrations with attributes such as a user identifier, topic, language, or application segment. Microsoft also supports tag expressions so a backend can combine tags when selecting an audience.

Templates are useful when the same logical notification needs different payload formats on different platforms. The device can register a template, and the backend can send data that the service maps into the platform-specific notification structure. Teams should keep tag design controlled because tags become part of the application's audience model, not merely a delivery setting.

Which platforms and backends does Notification Hubs support?

Microsoft positions Notification Hubs as a cross-platform push service. Its documentation covers major mobile push ecosystems and browser push, while backend applications can use Azure-hosted services, on-premises systems, SDKs, or the REST API. This makes it useful when one product has iOS, Android, Windows, or web clients and the backend team wants one common push layer.

Notification Hubs does not replace the platform notification systems themselves. Apple, Google, Windows, and other platform services still deliver the final push to the device. The hub handles registration, targeting, formatting, and fan-out between the application backend and those platform services.

How does Azure Notification Hubs pricing work?

Pricing checked: August 28, 2026. Microsoft currently offers Free, Basic, and Standard tiers. Billing and core quotas are applied at the namespace level, while notification volume above included amounts is aggregated at subscription level for each tier. The current Microsoft pricing page lists 1 million included pushes for Free and 10 million included pushes for both Basic and Standard, with overage behavior depending on tier.

The tiers also differ by active-device limits and features. Microsoft's current limits show 500 active devices for Free, 200,000 for Basic, and 10 million for Standard. Standard adds capabilities such as scheduled push, bulk import, richer telemetry, and multi-tenancy. Availability Zones and Private Link are presented as paid add-ons where supported. Exact charges vary by agreement, currency, region, and usage, so buyers should verify the Azure pricing page for their billing context.

What limits should teams check before deployment?

Current Microsoft limits list 100 hubs per namespace across the standard tier structure, with a documented request path for higher Standard hub counts. Microsoft also lists a quota of 60 tags per installation or registration. Active-device limits vary sharply by tier, so a proof of concept that works on Free can require a tier change before a production launch.

Namespace design matters because quotas and billing are tied to namespaces. Teams operating many applications, tenants, or regions should decide whether to isolate workloads into separate namespaces before registrations grow. A late namespace redesign can require moving or recreating registrations and platform credentials.

How are security and credentials handled?

Azure Notification Hubs uses Shared Access Signature policies with Listen, Send, and Manage rights. Microsoft creates a listen-only policy and a full-access policy by default. The full-access key is intended for trusted backend use and should not be embedded in client applications. Client registration scenarios should use the minimum rights needed, and sensitive targeting rules should be enforced by the backend when tags represent users or protected audience groups.

Microsoft also documents automatic encryption at rest for stored customer keys and data using service-managed encryption. For secure notification content, teams should remember that push platforms are delivery channels, not private application databases. Microsoft guidance for sensitive scenarios recommends sending a reference or identifier and retrieving protected content through an authenticated application backend.

What reliability and disaster recovery options are available?

Microsoft's current portal guidance allows a Notification Hubs namespace to be configured with no disaster recovery, a paired recovery region, or a flexible recovery region. In supported regions, Availability Zones can also be selected and are billed as an additional feature. These settings should be decided with the application's regional recovery requirements rather than treated as defaults.

Push delivery also depends on the external platform notification service and the state of the end device. A successful submission to Notification Hubs does not mean a user has seen the message. Teams that need business-level delivery confirmation should design application telemetry and fallback workflows rather than treating push acknowledgement as proof of user receipt.

How does Notification Hubs differ from Event Hubs and Service Bus?

Notification Hubs is for device and browser push notifications. Azure Event Hubs is for ingesting high-volume event streams from applications, devices, or services. Azure Service Bus is for reliable application messaging with queues and topics. They solve different parts of an architecture and should not be treated as substitutes simply because all three move messages.

An application might use Service Bus to coordinate backend work, Event Hubs to collect telemetry, and Notification Hubs to alert users. Keeping those roles separate makes capacity planning, reliability expectations, and search intent clearer.

Who should choose something else?

A small app that supports only one push platform and has simple targeting may be better served by calling that platform's notification service directly, especially when the team already maintains the required device-token registry. Notification Hubs adds the most value when cross-platform support, centralized registration management, segmentation, templates, or large-scale fan-out would otherwise require custom infrastructure.

Teams needing guaranteed application-to-application messaging should use a messaging service such as Service Bus rather than a push notification service. Teams building high-volume telemetry ingestion should evaluate Event Hubs. Buyers should choose Notification Hubs when the destination is an end-user device or browser and push-notification management is the actual problem to solve.