Stop asking “has anything changed yet?” and start being told when it does.

Applications constantly need to react to things that happen elsewhere. A file lands in storage and must be scanned. A virtual machine is created and must be tagged. An order is placed and several systems must hear about it. The simplest way to notice such changes is polling: a program repeatedly asks “anything new?” every few seconds. Polling works, but it is wasteful, because most checks find nothing, and slow, because changes are only noticed at the next check.

Azure Event Grid replaces polling with a push approach. It is a fully managed event routing service. Event sources, such as Azure services or your own applications, publish small notifications called events. Event Grid receives them and delivers each one to every interested handler, such as a function, a workflow, a queue or a web address. You write code only for what should happen in response, not for the plumbing that notices the change and carries the news.

This style is called event-driven architecture. Components stay loosely connected: a publisher does not know who will react, and a handler does not know who raised the event. New reactions can be added without touching the publisher at all.

What makes it special

Event Grid is designed for reactive, near-real-time notifications at very large scale, with pricing based on the number of operations rather than reserved capacity. It has built-in support for events from many Azure services, so in many cases you can react to something happening in Azure without writing any publishing code at all.

Choosing between Event Grid, Service Bus and Event Hubs starts with one question: what are you actually sending?

Azure offers several messaging services that sound similar. They solve different problems, and the key is to understand the difference between an event and a message.

flowchart TD
  A["What are you sending?"] --> B{"Something happened, tell interested parties?"}
  B -->|"Yes, discrete notifications"| EG["Event Grid"]
  A --> C{"A command or work item that must be processed reliably?"}
  C -->|"Yes, with ordering, sessions or transactions"| SB["Service Bus"]
  A --> D{"A continuous high-volume stream of data?"}
  D -->|"Yes, telemetry or logs"| EH["Event Hubs"]
  EG -.->|"Often combined"| SB
  EG -.->|"Often combined"| EH
        

A short vocabulary unlocks every portal screen and every design discussion.

Event Grid has a compact set of terms. Learn them once and the documentation becomes straightforward to follow.

Publishers on one side, handlers on the other, and a routing layer in between.

Event Grid sits between event sources and event handlers. It is managed entirely by Azure, so there are no servers, brokers or clusters to run. Your responsibility is to define topics, subscriptions, filters and handlers.

flowchart LR
  S1["Azure service events"] --> T1["System topic"]
  S2["Your application"] --> T2["Custom topic"]
  S3["Partner service"] --> T3["Partner topic"]
  T1 --> E1["Event subscription with filter"]
  T2 --> E2["Event subscription with filter"]
  T2 --> E3["Event subscription with filter"]
  T3 --> E4["Event subscription with filter"]
  E1 --> H1["Azure Function"]
  E2 --> H2["Logic App workflow"]
  E3 --> H3["Service Bus queue"]
  E4 --> H4["Webhook endpoint"]
        

Two flavours inside the service

Event Grid today offers two related feature sets. The original one, often described as the Basic tier, uses push delivery and covers system topics, custom topics, domains and partner topics. The newer one, based on namespaces, offers namespace topics with both push and pull delivery and a built-in broker for the MQTT messaging protocol, which suits devices. Understanding which features belong to which helps you choose and avoids looking for a capability in the wrong place.

From something happening to a handler reacting.

Following one event from start to finish shows how delivery, validation and retries fit together. The sequence below uses a push delivery to a web-based handler.

sequenceDiagram
  participant Src as Event source
  participant Topic as Topic
  participant EG as Event Grid delivery engine
  participant H as Event handler
  Note over EG,H: Subscription creation: handshake proves the endpoint is expected
  Src->>Topic: Publish event
  Topic->>EG: Match against subscriptions and filters
  EG->>H: Deliver event over HTTPS
  alt Handler accepts
    H-->>EG: Success response
    EG->>EG: Mark delivered
  else Handler fails or times out
    H-->>EG: Error or no response
    EG->>EG: Wait and retry with growing delay
    EG->>H: Deliver again
  end
        

The validation handshake

When you create a subscription that delivers to a web address, Event Grid first needs to know that the owner of that address really wants the events. It sends a special validation request, and the endpoint must respond correctly. This prevents someone from flooding a stranger’s endpoint with events. Azure-native handlers such as functions and queues are validated automatically, so this step mostly matters for custom web endpoints.

Many Azure services already speak Event Grid fluently.

One of the best features of Event Grid is that many Azure services publish events without any extra code. You simply create a subscription and start reacting. These are exposed through system topics.

Examples of what services announce

Your own applications

For your own business events, such as “order shipped” or “invoice approved”, you create a custom topic and publish to it. Choose clear event type names and consistent structures so that handlers written by different teams can rely on them.

Where events go, and who controls the pace.

A subscription must say where to deliver. Event Grid supports a rich set of destinations, and the choice shapes how your solution behaves under load and failure.

Push versus pull

Traditionally Event Grid pushes events to handlers: it calls your endpoint when events arrive. This is simple and fast but means your handler must be ready to accept whatever arrives. Namespace topics add pull delivery, where your consumer asks for events when it is ready, processes them and confirms or rejects them. Pull gives the consumer control over pace, which suits workers behind firewalls or systems that need to smooth out bursts.

Handlers should receive what they need, and nothing more.

A topic may carry thousands of events per minute of many kinds. A given handler usually cares about only a small slice. Filtering at the subscription level lets Event Grid do the sorting, so your code is not woken up for irrelevant events and you do not pay for needless executions.

flowchart TD
  U["Blob created events in storage account"] --> T["System topic"]
  T --> F1{"Subject starts with images/ and ends with .jpg?"}
  T --> F2{"Subject starts with invoices/ ?"}
  T --> F3{"Event data size above a threshold?"}
  F1 -->|"Match"| H1["Image resize function"]
  F2 -->|"Match"| H2["Invoice processing workflow"]
  F3 -->|"Match"| H3["Large file alert to Service Bus"]
        

Design tip: make subjects meaningful

For your own events, design the subject like a path that goes from general to specific, such as region, then department, then item. This lets subscribers filter by prefix and suffix cheaply, without inspecting the data.

Networks fail and handlers crash. A good design expects both.

Event Grid provides at-least-once delivery. That means it tries hard to make sure every event reaches every matching handler, and in rare cases an event may be delivered more than once. It does not promise that events arrive in the order they were published. Understanding these two facts shapes how you write handlers.

Retry behaviour

If delivery fails, because the handler returns an error, times out or cannot be reached, Event Grid waits and tries again, increasing the delay between attempts. You can configure the maximum number of attempts and how long an event stays eligible for delivery. Some errors, such as a clearly invalid endpoint or authorisation failure, are treated as permanent and may not be retried.

flowchart TD
  A["Event ready for delivery"] --> B["Send to handler"]
  B --> C{"Handler responded with success?"}
  C -->|"Yes"| D["Delivered, event complete"]
  C -->|"No"| E{"Retries left and event not expired?"}
  E -->|"Yes"| F["Wait with increasing delay"]
  F --> B
  E -->|"No"| G{"Dead-letter destination configured?"}
  G -->|"Yes"| H["Write event to dead-letter storage"]
  G -->|"No"| I["Event dropped"]
        

Dead-lettering

A dead-letter destination is a storage container where Event Grid writes events it could not deliver, along with the reason. Without it, such events vanish after retries are exhausted. With it, you can inspect failures, fix the handler and replay the events. Configure it for any subscription whose events matter.

Writing handlers that survive reality

The newer part of the service, built for control and for devices.

Event Grid namespaces extend the service in two important directions. They add new ways to consume events, and they add a messaging broker for devices and applications that use the lightweight MQTT protocol. Both arrived over recent years, and release notes show features moving from preview to general availability gradually, so always confirm the status of the specific feature you want.

Namespace topics

Namespace topics can deliver to subscribers by push, as before, or by pull. With pull delivery, consumers fetch events in batches, process them and then acknowledge, release or reject each one. Events that are not acknowledged become available again, which supports reliable processing without keeping a connection open for the service to call.

The MQTT broker

MQTT is a lightweight publish-subscribe protocol used widely by internet-of-things devices, vehicles and sensors. The broker in a namespace lets devices connect directly, publish to topics and subscribe to topics, with authentication through certificates or other supported methods. Messages can also be routed onwards, for example to other Azure services, so device data can feed the same event-driven pipelines as everything else.

An event is a contract between strangers. Design it carefully.

Events travel between teams and systems that may never speak to each other. The structure of an event is therefore a public agreement. A confusing or unstable event design causes pain for every subscriber.

Schemas

Event Grid supports its own event format and also the industry-standard CloudEvents format, a vendor-neutral way of describing events. Using CloudEvents is often a good choice for new custom topics, because the same events can be understood by other platforms. Each event has common fields such as an identifier, a type, a source, a time and a subject, plus a data section with details specific to that event.

Thin or fat events?

Events can contain information and can trigger actions, so both ends need protection.

A forged event could trigger a deployment or a payment, and a leaked event could expose data. Security therefore covers who is allowed to publish, who is allowed to receive and how the traffic travels between them.

A few shapes cover most real-world uses.

Once you know the building blocks, a small number of patterns appear again and again. Recognising them speeds up design.

flowchart LR
  U["User uploads a document"] --> B["Blob storage"]
  B --> T["Event Grid system topic"]
  T --> F["Function: validate and extract text"]
  T --> L["Logic App: notify owner"]
  T --> Q["Service Bus queue: heavy analysis workers"]
  Q --> W["Worker processes at its own pace"]
  W --> D["Results stored and published as new event"]
  D --> T2["Custom topic for downstream teams"]
        

Event-driven systems fail quietly unless you watch them.

When components are loosely connected, a broken handler does not raise an error for the publisher. Events simply go undelivered or unprocessed. Without monitoring you may only notice days later, when a business process turns out never to have run.

Metrics to watch

Other useful metrics include events dropped because no subscription matched, delivery attempts, delivery latency and, for namespaces, throughput unit usage and connection counts. Compare published with delivered counts: a growing gap is an early warning.

Logs and alerts

Cheap per event, but volumes and design choices add up.

Event Grid’s basic offering is priced mainly by the number of operations, such as publishing events, delivery attempts and management calls, with an included allowance each month. Namespaces use a capacity model measured in throughput units plus operations. Prices and allowances change, so check the official pricing page for current numbers rather than relying on older articles.

What drives cost

Scale, limits and resilience

The service scales to very high event volumes without you managing capacity, though documented limits apply to event size, batch size, number of subscriptions per topic and publishing rates. Namespaces add throughput units that can be adjusted, and an autoscale capability has been announced in preview for the standard tier. For resilience, Event Grid offers geo-disaster recovery options for supported resource types, and well-designed solutions also protect themselves by using dead-lettering and by making handlers idempotent so that replays are safe.

Loose coupling is wonderful in production and tricky to test.

Event-driven systems change how teams build and operate software. Because components are decoupled, you cannot read a single piece of code to see what will happen when an event is raised. The behaviour lives in the set of subscriptions, which makes documentation, testing and ownership especially important.

A sensible lifecycle

Shapes that scale, and shortcuts that hurt later.

Patterns worth adopting

Anti-patterns to avoid

Habits that separate quiet, dependable event systems from mysterious ones.

Best practices

• Pick the right service. Events to Event Grid, commands to Service Bus and streams to Event Hubs, combined where it helps.
• Filter at the subscription. Use type, subject and data filters so handlers run only when needed.
• Assume duplicates and disorder. Make handlers idempotent and carry sequence information when order matters.
• Always configure dead-lettering. Give failures a place to land and a person who reviews them.
• Use identities, not keys. Managed identities for delivery and Entra identities for publishing.
• Keep events small and stable. Thin payloads, clear types, versions and documented owners.
• Respond fast. Acknowledge quickly and process elsewhere.
• Monitor delivery and silence. Alert on failures, dead letters and missing expected events.
• Automate and document. Define topics and subscriptions in code and keep the event flow diagram current.
• Check feature maturity. Confirm whether capabilities such as namespace features are generally available before depending on them.

Common mistakes

How different organisations put the doorbell and notice board to work.

The following scenarios are typical patterns rather than descriptions of specific companies. They show how the same building blocks combine for very different needs.

Quick answers to questions that come up again and again.

Event Grid routes discrete event notifications to many handlers. Service Bus provides reliable enterprise messaging with queues, ordering and transactions. Event Hubs ingests large streams of telemetry. They are often combined.

Not as a log for later reading. It delivers events and retries failures for a limited time. Use dead-lettering to capture failures, and a durable store if you need history.

No. Delivery is at-least-once without ordering guarantees, so design handlers to tolerate duplicates and out-of-order arrival.

A topic that represents events published by an Azure service, so you can subscribe to them without writing any publishing code.

When your own application needs to announce business events, such as an order shipped, to other systems or teams.

A management container for many related topics, typically used when each tenant or customer has its own topic.

Event Grid retries with increasing delays until the retry limit or event lifetime is reached, then drops the event or writes it to dead-letter storage if configured.

With push, Event Grid calls your handler. With pull, available on namespace topics, your consumer fetches events when ready and acknowledges them. Pull gives the consumer control over pace.

Yes, through the MQTT broker in namespaces, which supports publish and subscribe messaging from devices, with routing onward to other services.

Prefer Entra identities for publishers and managed identities for delivery, use network restrictions where available, validate webhook requests and limit who can create subscriptions.

Not necessarily. Many have reached general availability while others, such as autoscale for namespaces, have appeared in preview. Check the release notes for the maturity of the exact feature you plan to use.

Azure Event Grid is the doorbell and notice board of the cloud. Sources announce small events, topics receive them, subscriptions filter them, and handlers such as functions, workflows, queues and web endpoints react, with retries, dead-lettering and managed identities supporting reliability and security. The original topic-based service handles Azure and application events, while namespaces add pull delivery and an MQTT broker for devices. Success depends on a few habits: choose Event Grid for discrete events and pair it with Service Bus or Event Hubs when you need ordering or streaming, make handlers idempotent, filter early, protect topics with identities rather than keys, configure dead-lettering, and monitor both failures and silence. Because newer namespace features are arriving continuously, always check which are generally available before you depend on them.