Do the math on that. 400 folders, polled every minute, is 576,000 Graph calls a day. Almost all of them return nothing new. And Graph doesn’t hand out that kind of call budget for free - you’ll be deep in 429 territory long before you get anywhere near “every minute”.

So I went push instead: Graph change notifications, delivered as HTTPS POSTs straight to an Azure Function - the setup from my rich notifications post. No polling, no wasted calls, mail arrives when mail arrives.

It worked, and it still had a smell. Every notification now targets my function directly, so every failure is mine to own: deploys, restarts, an hour of bad code, a burst the plan can’t absorb. Graph retries a little, but the guarantees are thin, and at hundreds of thousands of deliveries a month even a small fail ratio is real mail quietly lost. I wanted delivery to be someone else’s job, done smarter than I’d do it on a deadline. That someone turned out to be Azure Event Grid, and this post is the mental model I wish I’d had on day one. The concrete mail setup gets its own post later.

Push, Don’t Poll

The polling model makes you responsible for the question: “anything new?” asked over and over, mostly answered with no. The push model flips it. The system where things happen publishes an event when they happen, and your code gets invoked with the event as input. Nothing runs when nothing happens.

That’s the whole pitch, and it’s an old idea - webhooks have done this for years. What Event Grid adds is the production plumbing you’d otherwise write yourself: fan-out to multiple receivers, filtering, automatic retries with backoff, and a paper trail for the events that never made it.

Event Grid Is a Router, Not a Queue

This is the mental model that matters most, and the one I got wrong first.

Event Grid is a router. An event arrives at a topic, Event Grid looks at the subscriptions on that topic, pushes the event to every one that matches, and moves on. The event is not stored. There is no backlog to work through, no offset to rewind, no built-in replay. If you need to see an event again after it was delivered, that’s on you.

A queue like Service Bus is the opposite: it holds messages until a consumer takes them, guarantees order if you ask for it, and lets a slow consumer catch up later. The usual shorthand is events versus messages. An event is a fact: “a mail arrived”, “a blob was created”. The publisher doesn’t know or care who listens. A message is a command with an intended recipient: “provision this site”, “send this invoice”. My backend uses both, and they don’t compete - Service Bus carries the commands, Event Grid carries the facts.

If you catch yourself wanting order, backlog, or replay, you wanted a queue. If you want “poke my function when something happens, and don’t make me poll”, you want Event Grid.

Three Kinds of Event Grid Topics

A topic is the thing events are published to, and there are three flavors:

• System topics belong to Azure resources. A storage account can raise BlobCreated, a resource group can raise deployment events. You don’t create the publisher, you just subscribe.
• Custom topics are yours. Your own code POSTs events to an endpoint you own, and Event Grid routes them. Good for decoupling your own services.
• Partner topics are the interesting one for my scenario: an external service outside your subscription publishes into your Azure subscription. Microsoft Graph is such a partner, which is how mail notifications for 400 folders end up as events in my resource group without a single public webhook on my side.

One detail that surprised me: partner topics route by name. All 400 of my Graph subscriptions point at one shared partner topic. You do not get - or want - a topic per source.

Event Subscriptions Do the Filtering

A topic without subscriptions is a mailbox nobody checks. An event subscription says “from this topic, send events matching this filter to this handler”. Handlers can be Azure Functions, webhooks, Service Bus queues, storage queues, and more.

Filtering earns its keep once one topic carries more than one event type. My partner topic carries both new-mail notifications and subscription lifecycle events, with one subscription per function. You can filter by event type on each subscription so a function only receives its kind - or do what I ended up doing: skip the portal filters, let both functions receive everything, and have each one check the event’s type in code and drop what isn’t for it. Same routing, but the decision lives in code you can read and debug.

Here’s roughly what an event looks like on the wire. Partner topics use the CloudEvents schema, which is a small CNCF-standardized envelope:

{
  "specversion": "1.0",
  "id": "8f0f0e58-2c5e-4c4a-9f5e-4a1b2c3d4e5f",
  "source": "/tenants/<tenant-id>/applications/<app-id>",
  "type": "Microsoft.Graph.MessageCreated",
  "time": "2026-11-02T09:14:32Z",
  "data": {
    "subscriptionId": "<graph-subscription-id>",
    "changeType": "created",
    "resource": "Users/<user-id>/Messages/<message-id>",
    "clientState": "<shared-secret>"
  }
}

What’s happening here?

1. The envelope (id, source, type, time) is standard CloudEvents. Every event, from any publisher, has these fields, which is what makes generic routing and filtering possible.
2. type is what you route on, whether with a subscription filter or a check at the top of your handler. The mail types are documented in the Outlook events reference.
3. data is the publisher’s payload and can be anything. Note what it is here: pointers, not the mail itself. Events are notifications, not cargo ships.
4. clientState is a shared secret you set when subscribing, so your handler can check the event really originates from your subscription.

Retries and Dead-Letters: When Delivery Fails

This is where Event Grid stops being “just webhooks with extra steps”.

If a handler fails - throws, times out, returns a 5xx - Event Grid retries with exponential backoff for up to 24 hours. Your function can be down for a deploy, or an hour, or an evening, and the events still arrive when it comes back. No code on your side, it’s just what delivery means here.

When 24 hours run out, or the retry count is exhausted, the event is dead-lettered: written as a blob to a storage container you configure, together with the reason delivery failed. That container is your safety net and your crime scene evidence in one. Since Event Grid doesn’t store or replay events, the dead-letter container is also the only place a lost event can be recovered from, which makes it worth monitoring - that’s a whole post of its own later in this series.

One catch to design for: delivery is at-least-once. Retries mean your handler will occasionally see the same event twice, so make handling idempotent - dedupe on the event or message id rather than assuming exactly-once.

What Event Grid Costs

Event Grid’s basic tier charges $0.60 per million operations, and the first 100,000 operations each month are free. My mail scenario pushes roughly 300K events a month, which lands somewhere around twenty cents. The pipeline is a rounding error.

The real costs show up downstream: Application Insights ingestion if you log a line per event, and whatever your handler talks to. In my case the constraint was never Event Grid, it was the Graph throttling budget and the write throughput of the archive behind it. Event Grid just makes sure the events get to the code; what the code does next is still your problem.

Gotchas

• No replay means no replay. If your handler had a bug and quietly swallowed events for a week, those events are gone unless they were dead-lettered. Design your handler to fail loudly on real errors so retries and dead-lettering can do their job.
• Delivery is at-least-once. The same event can arrive twice. Idempotent handlers aren’t optional.
• Events are pointers, not payloads. The event tells you something happened, and mostly not everything about it. Plan for the follow-up read, or use a publisher feature that includes the data (Graph can, with encryption attached).
• Don’t reach for Event Grid when you want a queue. Order, backlog, and consumer-paced processing are queue features. I’ve seen the mismatch from both sides, and the workarounds are uglier than just using Service Bus.

Wrapping Up

Event Grid is push-based routing of facts: publishers raise events at topics, subscriptions filter and deliver them to handlers, retries cover about 24 hours, and dead-letters catch the rest. It saved me from 576,000 daily “anything new?” calls, and then took the delivery failures off my plate too. The one-line rule of thumb: events for facts, queues for commands, and never poll for what Azure will push to you.

Next up in this series: actually wiring Microsoft Graph mail notifications to an Azure Function through a partner topic.