Skip to article
Integration Event Grid

Event Grid topic

An Event Grid topic is an endpoint where events are published and then routed by event subscriptions to configured event handlers.

Source: Microsoft Learn - Concepts in Azure Event Grid Reviewed 2026-06-03

Exam trap
Treating event Grid topic as a diagram label instead of checking the exact source, subscription, handler, identity, and live configuration.
Production check
Verify source resource ID, subscription name, destination type, schema, filters, retry policy, dead-letter settings, and owning team.
Practice this topic Microsoft Learn
Article details and learning context
Aliases
Azure Event Grid topic, custom topic, Event Grid custom topic
Difficulty
intermediate
CLI mappings
4
Last verified
2026-06-03
Review level
launch-ready
Article depth
field-manual-complete
Learning paths Learn Messaging and Streaming Foundations Event Grid topic
Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

An Event Grid topic is an endpoint where events are published and then routed by event subscriptions to configured event handlers. Teams use it to publish events into Event Grid so subscriptions can route matching events to handlers, queues, workflows, streams, or webhooks. It is not the same thing as an Event Hubs stream, Service Bus topic, or a handler that processes events. In production, confirm the source, subscription, destination, filters, schema, identity, retry behavior, failure handling, monitoring, and owner before treating the route as safe.

Why it matters

Event Grid topic matters because it is the publishing entry point that separates event producers from consumers, allowing new subscribers and workflows without changing publisher code every time. Without clear vocabulary, teams may confuse topics with handlers, publish to the wrong endpoint, expose keys, create broad subscriptions, or assume accepted events were processed downstream. It also affects security, reliability, operations, cost, and performance because one routing or destination setting can change who receives events, when retries happen, where failures are stored, and how handlers scale. Good glossary discipline helps teams ask who owns it, which event types are in scope, what evidence proves the current state, and what rollback path exists before an incident, audit, or release.

Technical context

Technically, event Grid topic is configured through topic endpoints, access keys or identity configuration, publisher requests, event schema, event subscriptions, filters, destinations, retry policy, dead-letter destinations, and diagnostics. It depends on publisher authentication, event schema choice, event subscription design, handler readiness, RBAC, network requirements, metrics, and source ownership. Operators inspect it through the portal, ARM or Bicep, Azure CLI, Monitor metrics, diagnostic logs, and handler evidence. For troubleshooting, connect source resource ID, schema, endpoint authentication, Activity Log changes, and destination logs before changing routing.

Exam context

Compare with

Event Hub Service Bus topic Event Grid event subscription

Where it is used

Where you see it

  1. Topic blades show endpoint, keys, region, schema, identity, and metrics that prove where publishers send events before subscriptions route them during release review and incident triage.
  2. Event subscription lists reveal which handlers receive topic events, which filters apply, and whether retry and dead-letter settings protect delivery during release review and incident triage.
  3. Publisher logs, Event Grid metrics, and handler logs together show whether events were accepted, matched, delivered, retried, or failed downstream during release review and incident triage.

Common situations

  • Publish custom application events through a managed Event Grid endpoint.
  • Route topic events to handlers through event subscriptions and filters.
  • Review publisher keys, identity, schema, retry, and dead-letter behavior before launch.
  • Separate event publication from consumer workflows so subscribers can evolve independently.
  • Troubleshoot failed deliveries by checking topic metrics, subscriptions, and destination health.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Event Grid topic in action for consumer electronics support Scenario, objectives, solution, measured impact, and takeaway.
Scenario

Apex Warranty Services, a consumer electronics support organization, needed to solve a production challenge: device registration events needed to notify warranty, support, and analytics teams without direct integrations from the registration service. The architecture team used Event Grid topic to make the workflow measurable, governable, and easier to support.

Goals
  • Create one publishing endpoint for registration events
  • Add subscribers without publisher changes
  • Track delivery health across handlers
  • Reduce integration code ownership conflicts
Approach using Event Grid topic

The architecture team created an Event Grid topic for deviceRegistrationCreated and warrantyActivated events. The registration service published events to the topic, while event subscriptions routed support events to Azure Functions, analytics events to Event Hubs, and warranty events to Service Bus. Filters, schema samples, dead-letter storage, and metrics were documented. The team connected the design to Event Grid source scope, event subscriptions, filters, delivery schema, handler ownership, retry behavior, dead-letter handling, Azure Monitor dashboards, and documented rollback steps. Before cutover, engineers sent test events, compared expected matches with actual metrics, reviewed identity or endpoint access, and stored CLI evidence in the change record. Operators received a runbook with sample payloads, first-response checks, and clear escalation paths for publisher, Event Grid, handler, and downstream dependency issues.

Potential outcomes
  • Three direct service integrations were replaced by one topic
  • New analytics subscribers were added in one release cycle
  • Support event delivery stayed below four seconds in testing
  • Integration ownership moved from ad hoc code to reviewed subscriptions
What to learn

A topic gives publishers one managed event entry point while consumers evolve independently.

Scenario 02 Event Grid topic in action for grocery retail Scenario, objectives, solution, measured impact, and takeaway.
Scenario

HarborFoods Market, a grocery retail organization, needed to solve a production challenge: store inventory changes were copied into multiple APIs and caused inconsistent stock alerts during holiday demand. The architecture team used Event Grid topic to make the workflow measurable, governable, and easier to support.

Goals
  • Centralize inventory event publishing
  • Reduce duplicated notification code
  • Route perishable inventory events separately
  • Expose delivery failures to operations
Approach using Event Grid topic

Engineers built a custom Event Grid topic for inventoryAdjusted and itemExpired events. Store systems published one event per inventory change, and subscriptions routed perishable alerts to Logic Apps, replenishment messages to Service Bus, and analytics to Event Hubs. Operators monitored published, matched, and failed events. The team connected the design to Event Grid source scope, event subscriptions, filters, delivery schema, handler ownership, retry behavior, dead-letter handling, Azure Monitor dashboards, and documented rollback steps. Before cutover, engineers sent test events, compared expected matches with actual metrics, reviewed identity or endpoint access, and stored CLI evidence in the change record. Operators received a runbook with sample payloads, first-response checks, and clear escalation paths for publisher, Event Grid, handler, and downstream dependency issues.

Potential outcomes
  • Duplicated inventory webhook code dropped by 52 percent
  • Perishable stock alerts arrived within three seconds
  • Dead-letter review caught one handler authorization issue
  • Holiday support used one dashboard for inventory event health
What to learn

Event Grid topics reduce point-to-point integration sprawl when many consumers need the same business events.

Scenario 03 Event Grid topic in action for industrial automation Scenario, objectives, solution, measured impact, and takeaway.
Scenario

NexBridge Robotics, a industrial automation organization, needed to solve a production challenge: robot quality events needed to reach maintenance and reporting systems without slowing production-line controllers. The architecture team used Event Grid topic to make the workflow measurable, governable, and easier to support.

Goals
  • Avoid controller-side integrations
  • Fan out quality events to maintenance and analytics
  • Keep handlers independent from publishers
  • Prove event delivery during line incidents
Approach using Event Grid topic

Controllers published qualityFlagged and calibrationCompleted events to an Event Grid topic. Maintenance subscriptions used subject filters for affected lines, while analytics received all quality events through Event Hubs. The team protected topic keys, validated schema examples, and added metrics to the plant operations dashboard. The team connected the design to Event Grid source scope, event subscriptions, filters, delivery schema, handler ownership, retry behavior, dead-letter handling, Azure Monitor dashboards, and documented rollback steps. Before cutover, engineers sent test events, compared expected matches with actual metrics, reviewed identity or endpoint access, and stored CLI evidence in the change record. Operators received a runbook with sample payloads, first-response checks, and clear escalation paths for publisher, Event Grid, handler, and downstream dependency issues.

Potential outcomes
  • Controller release complexity dropped by 38 percent
  • Maintenance tickets opened in under one minute
  • Analytics received complete quality event streams
  • Incident reviews correlated topic metrics with handler logs
What to learn

Topics are the clean boundary between producing events and deciding who acts on them.

Azure CLI

Azure CLI helps validate event Grid topic because it captures reproducible evidence for source scope, subscription settings, filters, schema, destinations, retry behavior, dead-letter paths, identity, and metrics before a production change.

Useful for

  • List or show the Event Grid resource and related subscriptions for event Grid topic.
  • Capture read-only evidence before approving a routing, identity, filter, retry, or destination change.
  • Compare Event Grid metrics with handler logs during delivery, authorization, or processing incidents.

Before you run a command

  • Confirm the tenant, subscription, resource group, source resource ID, handler, and environment are the intended scope.
  • Run read-only list, show, and metrics commands before any create, update, delete, key, identity, or destination change.
  • Get approval for mutating commands because Event Grid changes can reroute events, expose data, stop automation, or create new costs.

What the output tells you

  • Resource IDs, endpoints, schemas, filters, identities, and retry settings show what Event Grid is configured to do right now.
  • Metrics and logs show whether events are being published, matched, delivered, retried, dead-lettered, or blocked by authorization.
  • Destination and handler evidence shows whether the issue is Event Grid routing, endpoint authentication, application processing, or downstream capacity.

Mapped commands

Event Grid topic validation CLI commands

direct 
az eventgrid topic list --resource-group <resource-group> --output table
az eventgrid topicdiscoverIntegration
read-only Microsoft Learn 
az eventgrid topic show --name <topic-name> --resource-group <resource-group>
az eventgrid topicdiscoverIntegration
read-only Microsoft Learn 
az eventgrid topic create --name <topic-name> --resource-group <resource-group> --location <region>
az eventgrid topicprovisionIntegration
mutating Microsoft Learn 
az eventgrid event-subscription list --source-resource-id <topic-resource-id> --output table
az eventgrid event-subscriptiondiscoverIntegration
read-only Microsoft Learn 
az monitor metrics list --resource <topic-resource-id> --interval PT1H
az monitor metricsdiscoverIntegration
read-only Microsoft Learn

Architecture context

An Event Grid topic is the publish-and-subscribe boundary for custom application events or namespace-based event flows. In architecture terms, it separates producers from consumers while preserving event metadata, filtering, fan-out, retry, and delivery diagnostics. Teams use topics when a domain event, integration signal, or automation trigger must reach multiple handlers without direct service-to-service coupling. The design should define event schema, subject naming, publisher identity, allowed event types, subscription ownership, and dead-letter behavior before production traffic arrives. A topic is not a dumping ground for every notification. Strong designs align topics to bounded business domains or operational streams so routing rules, cost, monitoring, and incident ownership stay understandable.

Security
Security for event Grid topic starts with knowing which identities, keys, roles, endpoints, publishers, and handlers can create, receive, change, or recover events. Review publisher authentication, topic endpoint protection, subscription ownership, schema validation, failed delivery monitoring, key rotation, and clear separation between publisher and handler responsibilities before approving production changes. Prefer least privilege, managed identities, private networking, and explicit authorization where supported. Protect payloads because event metadata can reveal tenant IDs, resource names, device identifiers, customer activity, or operational workflow details. During audits, capture Activity Log entries, subscription settings, handler authentication, dead-letter access, and owner approvals so the team can prove event data only flows to intended destinations.
Cost
Cost for event Grid topic usually appears through event operations, delivery attempts, handler executions, downstream queues or streams, diagnostic logs, dead-letter storage, and staff time spent investigating noisy routes. Broad filters, duplicate subscriptions, failing endpoints, over-retained logs, or oversized event payloads can turn a small event path into ongoing waste. Review expected event rate, matched count, retry count, logging retention, and destination cost together. Tag owners and environments clearly, retire unused subscriptions, and avoid sending events to handlers that immediately discard them. Keep this evidence visible in the runbook so support, security, and application teams can act without guessing during incidents.
Reliability
Reliability for event Grid topic depends on matching the event source, subscription, filter, schema, destination, retry behavior, and handler health. Event Grid can accept or match an event while the final business action still fails, so measure publish, match, delivery, acknowledgement, and handler processing separately. Test endpoint outage, authorization failure, malformed payload, throttling, duplicate delivery, and stale filter scenarios. Keep dead-letter review and replay procedures documented. During incidents, compare metrics, diagnostic logs, handler logs, and recent configuration changes before changing routes or increasing retries. Keep this evidence visible in the runbook so support, security, and application teams can act without guessing during incidents.
Performance
Performance for event Grid topic is about moving the right events at the right pace without overwhelming publishers, Event Grid resources, destinations, or downstream dependencies. Watch event size, publish rate, matched event count, delivery latency, retries, handler duration, cold starts, queue depth, and consumer acknowledgement behavior where applicable. Use precise filters, scalable handlers, private networking only where needed, and buffering patterns when downstream systems cannot accept bursts. Performance reviews should include the full path from source event creation to completed business action, not only Event Grid delivery metrics. Keep this evidence visible in the runbook so support, security, and application teams can act without guessing during incidents.
Operations
Operations for event Grid topic should be runbook-driven and evidence-first. The runbook needs the resource ID, owner, source, destination, event types, schema, filters, identities, retry policy, dead-letter path, dashboard, and approved mutating commands. Operators should know which metric proves publishing, matching, delivery, backlog, or handler failure. Change tickets should include sample events, expected matches, rollback instructions, and approval owners. When support receives an alert, the first step is to locate the exact source and subscription, not restart every related service or rewrite the handler. Keep this evidence visible in the runbook so support, security, and application teams can act without guessing during incidents.

Common mistakes

  • Treating event Grid topic as a diagram label instead of checking the exact source, subscription, handler, identity, and live configuration.
  • Changing filters, retry policy, destination settings, or endpoint authentication without saving read-only evidence and rollback instructions.
  • Assuming Event Grid delivery means the downstream business action completed successfully, even when the handler failed or ignored the event.