Integration Event Grid premium

Event subscription

An Event subscription is an Event Grid configuration that selects events from a source and delivers matching events to a destination endpoint. Teams use it to route storage, resource, custom, or partner events to the correct webhook, function, queue, topic, or event handler. It is not the event source itself, an Azure subscription, an Event Hubs consumer group, or proof that the destination successfully processed every event. In production, confirm source scope, event types, filters, endpoint URL or resource ID, authentication method, dead-letter destination, retry settings, diagnostic logs, and receiving application owner before treating the design as healthy or ready.

Back to glossary browser Open Microsoft Learn source
Aliases
Event Grid subscription, event routing subscription, event delivery subscription
Difficulty
intermediate
CLI mappings
6
Last verified
2026-05-14

Microsoft Learn

An Event subscription is an Event Grid configuration that selects events from a source and delivers matching events to a destination endpoint.

Microsoft Learn: Azure Event Grid documentation2026-05-14

Technical context

Technically, the Event subscription is configured or observed through Event Grid topic or system topic scope, endpoint type, subject filters, advanced filters, delivery schema, retry policy, dead-letter destination, managed identity delivery, and endpoint validation records. It depends on an event source, an Event Grid topic or system topic, destination endpoint readiness, identity permissions, network access, filters, retry settings, dead-letter storage, diagnostics, and ownership of the receiving application. Operators inspect it through the Azure portal, ARM or Bicep, Azure CLI, SDK or REST calls, Azure Monitor, diagnostic logs, and application telemetry.

Why it matters

Event subscription matters because it is the routing contract that decides which event notifications leave the source and where they are sent. Without clear vocabulary, teams may subscribe too broadly, miss critical event types, expose endpoints, skip dead-letter handling, duplicate deliveries, or blame Event Grid when the destination rejected valid events. It also affects security, reliability, operations, cost, and performance because one configuration choice can change who can act, what fails, how quickly work completes, what evidence exists, and how much the platform costs. Good glossary discipline helps teams ask who owns it, what depends on it, which metric proves health, and what rollback path exists before a release.

Where you see it

Signals, screens, and Azure surfaces where this term usually becomes operational.

Signal 01

Event Grid pages show an event subscription with source resource ID, destination endpoint, included event types, subject filters, advanced filters, retry policy, and dead-letter settings.

Signal 02

Activity Log records show create, update, or delete operations on event subscriptions near the same time that downstream handlers stopped receiving expected events. Review scope, owners, metrics, and rollback evidence.

Signal 03

Delivery failure logs mention endpoint validation, authentication failure, HTTP status codes, dead-letter writes, or retry attempts for a specific subscription name. Review scope, owners, metrics, and rollback evidence.

When this becomes relevant

Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.

  • Route selected Event Grid events from a source to a production handler.
  • Audit delivery, filtering, retry, and dead-letter settings before a release.
  • Troubleshoot missing, duplicated, or rejected event notifications across source and destination teams.
  • Support incident response by correlating Azure configuration, diagnostic logs, metrics, deployment history, and application traces.

Real-world case studies

Different enterprise-style examples that show the term being used to hit measurable objectives.

Case study 01

Event subscription in action for electric utility

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Riverton Utilities, a electric utility organization, needed to solve a production challenge: smart-meter storage events were routed to multiple handlers, but billing updates missed some blob-created notifications during monthly close. The architecture team used Event subscription to make the design measurable, governable, and easier to support.

Business/Technical Objectives
  • Deliver billing events within five minutes
  • Limit subscriptions to approved containers
  • Capture failed deliveries for replay
  • Give support a single subscription owner
Solution Using Event subscription

Architects consolidated the storage event route into one Event Grid event subscription scoped to the billing container. They used subject filters for invoice files, delivered to an Azure Function with managed identity, configured dead-letter storage, and added alerts for delivery failures and endpoint validation changes. Before cutover, engineers captured read-only configuration, validated identity and network access, compared expected behavior with Azure Monitor or service logs, and stored rollback instructions in the change record. Operators received a runbook with first-response checks, known failure modes, owner contacts, and escalation paths. The team also reviewed owner tags, diagnostic coverage, alert routing, and incident communication paths so support could confirm the workflow without changing production state.

Results & Business Impact
  • Billing event misses fell from twelve per month to zero
  • Dead-letter replay handled two endpoint outages without data loss
  • Subscription ownership became visible in the runbook
  • Monthly close finished 18 percent faster
Key Takeaway for Glossary Readers

An event subscription is valuable because it makes event routing explicit, filterable, and supportable.

Case study 02

Event subscription in action for healthcare

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Harbor Clinic Network, a healthcare organization, needed to solve a production challenge: patient document uploads needed to trigger secure processing without exposing a public webhook to every storage event. The architecture team used Event subscription to make the design measurable, governable, and easier to support.

Business/Technical Objectives
  • Trigger processing only for protected folders
  • Avoid over-broad event delivery
  • Preserve failure evidence
  • Meet audit review requirements
Solution Using Event subscription

The team created an Event Grid subscription from the storage account system topic to a private processing workflow endpoint. Advanced filters selected protected document paths, dead-letter storage retained failed deliveries, and diagnostic settings sent delivery evidence to Log Analytics for compliance review. Before cutover, engineers captured read-only configuration, validated identity and network access, compared expected behavior with Azure Monitor or service logs, and stored rollback instructions in the change record. Operators received a runbook with first-response checks, known failure modes, owner contacts, and escalation paths. The team also reviewed owner tags, diagnostic coverage, alert routing, and incident communication paths so support could confirm the workflow without changing production state. The team also reviewed owner tags, diagnostic coverage, alert routing, and incident communication paths so support could confirm the workflow without changing production state.

Results & Business Impact
  • Unrelated events stopped reaching the workflow
  • Audit reviewers traced every failed delivery
  • Processing delays dropped below ten minutes
  • Endpoint changes required approved change records
Key Takeaway for Glossary Readers

Precise event subscriptions reduce noise and create the evidence auditors need for event-driven workflows.

Case study 03

Event subscription in action for retail ecommerce

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

PeakTrail Retail, a retail ecommerce organization, needed to solve a production challenge: order-created events from a custom topic were reaching two fulfillment systems and causing duplicate warehouse picks. The architecture team used Event subscription to make the design measurable, governable, and easier to support.

Business/Technical Objectives
  • Remove duplicate order routing
  • Keep warehouse events replayable
  • Separate test and production destinations
  • Improve incident diagnosis
Solution Using Event subscription

Engineers reviewed all Event Grid event subscriptions on the custom topic, deleted the stale test destination, and added naming standards for fulfillment routes. They configured dead-lettering, captured subscription settings with CLI before changes, and correlated delivery logs with warehouse application traces. Before cutover, engineers captured read-only configuration, validated identity and network access, compared expected behavior with Azure Monitor or service logs, and stored rollback instructions in the change record. Operators received a runbook with first-response checks, known failure modes, owner contacts, and escalation paths. The team also reviewed owner tags, diagnostic coverage, alert routing, and incident communication paths so support could confirm the workflow without changing production state.

Results & Business Impact
  • Duplicate warehouse picks dropped by 96 percent
  • Replay evidence was available for missed events
  • Test endpoints were isolated from production topics
  • Mean diagnosis time fell from two hours to 25 minutes
Key Takeaway for Glossary Readers

Event subscriptions are where routing mistakes become real business outcomes, so they deserve operational review.

Why use Azure CLI for this?

Azure CLI helps validate Event subscription because it captures reproducible evidence for scope, configuration, permissions, runtime state, diagnostics, and related resources before a production change.

CLI use cases

  • List or show Azure resources and related configuration for Event subscription.
  • Capture read-only evidence before changing identity, networking, triggers, capacity, policy, deployment, or automation settings.
  • Compare Azure metrics, logs, run history, deployment operations, and application evidence during production incidents.

Before you run CLI

  • Confirm the tenant, subscription, resource group, resource names, environment, and time window are the intended scope.
  • Run read-only list, show, metrics, operation, or query commands before any create, update, delete, start, stop, policy, or deployment change.
  • Get approval for mutating commands because configuration changes can expose data, break workflows, increase cost, or alter compliance evidence.

What output tells you

  • Resource IDs, enabled state, configuration values, identity settings, network posture, and ownership metadata show the current design.
  • Metrics, logs, run history, or deployment operations show whether the platform behaved as expected during the reviewed time window.
  • Application and downstream evidence shows whether the issue is Azure configuration, permissions, client behavior, data readiness, or business processing.

Mapped Azure CLI commands

Some evidence is visible only in service logs, SDK behavior, deployment output, or application telemetry; Azure CLI still validates surrounding resources and operational scope.

Architecture context

An Event Grid event subscription is the routing contract between an event source and an event handler. Architecturally, it sits at the edge of automation, integration, and serverless workflows: filters decide which events matter, the endpoint decides who receives them, and delivery settings decide what happens when the handler is unhealthy. I design subscriptions with source scope, subject filters, advanced filters, delivery schema, retry policy, dead-letter destination, endpoint authentication, and monitoring as one package. A subscription that points to a public webhook has a different risk profile from one using managed identity to deliver to a private-capable Azure service. Good designs include test events, dead-letter review, endpoint health alerts, and IaC ownership so routing changes are auditable.

Security

Security for the Event subscription starts with knowing who can create subscriptions, change destinations, set managed identities, read event payloads, approve webhook validation, manage dead-letter storage, and view diagnostic logs that may reveal operational metadata. Review source scope, event types, filters, endpoint URL or resource ID, authentication method, dead-letter destination, retry settings, diagnostic logs, and receiving application owner before approving production changes. Prefer managed identity and Microsoft Entra ID where the service supports it, keep secrets in approved vaults, scope roles narrowly, and protect diagnostics that may reveal sensitive names, payloads, or operational patterns. During audits, capture Activity Log entries, role assignments, network settings, diagnostic settings, and owner approvals so teams can prove access and behavior were intentional.

Cost

Cost for the Event subscription is driven by event volume, over-broad filters, duplicate subscriptions, dead-letter storage, diagnostics, downstream function executions, queue operations, webhook processing, and remediation work for misrouted events. The expensive mistake is not only Azure consumption; it is also duplicate processing, failed retries, audit cleanup, manual investigations, and unnecessary capacity caused by weak design evidence. Review whether the workload truly needs the selected tier, frequency, retention, diagnostics, network path, and automation pattern. Use tags, budgets, alerts, and recurring reviews so teams can explain why the current design exists and remove stale resources safely. This keeps Event subscription review specific across architecture, security, operations, and incident response.

Reliability

Reliability for the Event subscription depends on endpoint validation, retry policy, dead-letter destination, event filtering accuracy, destination capacity, managed identity permissions, private networking where supported, and monitoring of delivery failures. A healthy Azure resource can still fail the business workflow if downstream services, identities, triggers, clients, or data contracts are wrong. Test retries, failover assumptions, disabled states, stale configuration, private DNS problems, timeout behavior, and duplicate processing before relying on the design. Keep runbooks for first-response checks, known limits, owner escalation, and rollback so support teams can recover without guessing. This keeps Event subscription review specific across architecture, security, operations, and incident response.

Performance

Performance for the Event subscription depends on filter selectivity, endpoint responsiveness, retry behavior, destination throttling, payload size, delivery schema, DNS and network path, and downstream concurrency limits. Measure platform-side metrics and application-side completion metrics because fast service response does not always mean the business task finished. Use realistic data sizes, concurrency, filter patterns, region placement, authentication paths, and downstream limits in tests. When performance regresses, compare configuration changes, resource limits, client logs, diagnostic data, and workload timing before adding capacity or blaming one Azure service. This keeps Event subscription review specific across architecture, security, operations, and incident response. This keeps Event subscription review specific across architecture, security, operations, and incident response.

Operations

Operations for the Event subscription require named owners, documented resource IDs, expected behavior, diagnostic settings, and first-response checks. Before a change, capture read-only CLI output, portal screenshots when useful, deployment history, and relevant application configuration. During incidents, avoid changing several settings at once. Compare service metrics, logs, run history, identity evidence, network state, and downstream health in the same time window. Keep release notes clear enough for support teams to verify current behavior quickly. This keeps Event subscription review specific across architecture, security, operations, and incident response. This keeps Event subscription review specific across architecture, security, operations, and incident response.

Common mistakes

  • Treating Event subscription as a label instead of checking the exact resource scope, live configuration, owner, and dependencies.
  • Changing several settings at once without saving read-only evidence, rollback instructions, and the expected metric change.
  • Assuming the Azure resource succeeded means the end-to-end business workflow completed correctly and safely.