An ACR webhook is an Azure Container Registry event notification that sends an HTTP or HTTPS request to a configured endpoint when registry actions occur, such as image push or delete. It can be registry-wide or scoped to a repository or tag, including regional replicas.
An ACR webhook is an Azure Container Registry event notification that sends an HTTP or HTTPS request to a configured endpoint when registry actions occur, such as image push or delete. It can be registry-wide or scoped to a repository or tag, including regional replicas.
Microsoft Learn: Using Azure Container Registry webhooks2026-05-08
In Azure architecture, this term sits in the container artifact lifecycle: source code becomes an image or OCI artifact, the registry stores it, deployment platforms such as AKS and Azure Container Apps pull it, and operators use metadata to prove what was built, promoted, scanned, or removed. The control plane includes the ACR resource, repository settings, token or scope-map objects, task definitions, webhook definitions, and policy settings. The data plane includes pushes, pulls, tags, manifests, layers, and credential use by clients. A safe design treats registry content as production supply-chain evidence, not just files in a private Docker store. For ACR webhook, the important fields are action triggers, service URI, custom headers, status, repository or tag scope, delivery history, and regional replica for geo-replicated registries. The endpoint must be reachable by the registry and should authenticate incoming requests.
This matters because container mistakes travel quickly. A wrong repository name, overly broad token, accidental tag deletion, missed rebuild, noisy webhook, or blind retention rule can break deployments, expose private images, raise storage cost, or hide the evidence needed during an incident. The practical habit is to ask what artifact boundary the term controls, who owns that boundary, which workload consumes it, what command proves the current state, and what rollback evidence must be preserved before a cleanup, credential, or automation change is made. For ACR webhook, the most useful evidence is not the product label; it is the concrete output that shows current state, ownership, scope, and the next safe action.
Signals, screens, and Azure surfaces where this term usually becomes operational.
ACR webhooks
image push automation
vulnerability scan triggers
registry event delivery
az acr webhook commands
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Different enterprise-style examples that show the term being used to hit measurable objectives.
Scenario, objectives, solution, measured impact, and takeaway.
Meridian Sportswear wanted an automated notification whenever a new production image was pushed, but release coordinators were still watching pipeline pages manually.
The platform team created an ACR webhook scoped to `retail/web-api:prod-*` and configured it to trigger on image push events. The webhook sent HTTPS POST notifications to a public endpoint fronted by API Management, which validated a shared header and forwarded the event to a Logic App. Operators used the webhook ping command before production enablement and reviewed `az acr webhook list-events` after the first pushes. For the geo-replicated registry, the webhook was configured in the regional replica that served the deployment workload, so events matched the region where releases occurred. The runbook also recorded the owner, scope, verification command, rollback contact, and evidence to save after the change so operators could repeat the pattern safely.
An ACR webhook turns registry events into automation signals, but only when scope and endpoint security are deliberate.
Scenario, objectives, solution, measured impact, and takeaway.
HorizonGrid Energy needed to start vulnerability scanning whenever a container image was pushed to a shared registry repository.
Security engineering created an ACR webhook for push actions on `production/*` repositories. The service URI pointed to a hardened scanner gateway that accepted only authenticated webhook requests. When ACR sent the event payload, the gateway queued a scan using repository, tag, and digest details from the event. Operators tested the webhook with ping before enabling it, then checked delivery events after several sample pushes. The scanner posted results back to Azure DevOps, blocking deployment if the digest failed policy. Webhook configuration was included in the registry runbook with owner, URI, scope, actions, and expected response code. The runbook also recorded the owner, scope, verification command, rollback contact, and evidence to save after the change so operators could repeat the pattern safely.
ACR webhooks are useful when registry changes need immediate downstream action and auditable delivery evidence.
Scenario, objectives, solution, measured impact, and takeaway.
CivicRoute Transit operated separate container deployments in East US and West US and needed region-aware automation after image deletion events.
The container platform group configured ACR webhooks in each regional registry replica, with scopes limited to the repositories used by that region's AKS clusters. Delete events flowed to a regional Azure Function endpoint that enriched the payload with environment and owner metadata. Before enabling delete alerts, operators used the webhook ping action and reviewed the response code. Event history was checked after each cleanup window, and the function created a ticket only when a deleted tag matched the rollback retention watchlist. This made image deletion visible without flooding operations with every registry event. The runbook also recorded the owner, scope, verification command, rollback contact, and evidence to save after the change so operators could repeat the pattern safely.
A scoped ACR webhook connects registry events to operations without turning every image change into noise.
Azure CLI is useful for ACR webhook because it turns portal-visible configuration into repeatable evidence. Operators can list the target, inspect IDs and state, confirm whether the command is read-only or mutating, and save sanitized output for release or incident records. For this term, CLI work should start with context checks such as tenant, subscription, resource group, registry, database, role scope, or resource ID. Use JSON output when tags, digests, receiver lists, token permissions, assignment scopes, metrics, or replica links matter. Treat commands that delete manifests, disable tokens, update scope maps, create alerts, or fail over databases as approval-required changes, not casual inspection.
az acr webhook list --registry <registry-name> --resource-group <resource-group> --output tableaz acr webhook create --registry <registry-name> --name <webhook-name> --actions push --uri <https-endpoint>az acr webhook ping --registry <registry-name> --name <webhook-name>az acr webhook list-events --registry <registry-name> --name <webhook-name>az acr webhook delete --registry <registry-name> --name <webhook-name>Use webhooks when a registry action should start external automation quickly, such as scanning, deployment notification, or ticket creation. Scope them narrowly, test with ping before production, monitor delivery events, and avoid treating webhook delivery as a replacement for deployment approval.
Security depends on treating the registry as part of the software supply chain. Verify who can push, pull, delete, update metadata, trigger automation, or read event payloads. Prefer managed identity or Microsoft Entra integration for Azure workloads where it fits, use repository-scoped tokens only when needed, avoid registry admin credentials, and keep secrets out of command lines and logs. For ACR webhook, save evidence that proves the repository, token, scope, trigger, task, or policy affects only the intended image boundary.
Cost is usually indirect but real. Registry storage grows through repeated tags, orphaned manifests, large layers, retained rollback images, and build artifacts. Tasks can add build/run consumption, webhooks and scanners can trigger downstream cost, and over-segmentation can create unnecessary registries. For ACR webhook, cost control comes from clear image lifecycle rules, unique tagging, retention reviewed against rollback needs, and evidence that cleanup is removing waste rather than deleting still-needed production artifacts.
Reliability depends on preserving the artifacts and automation that workloads actually consume. A missing tag, deleted manifest, disabled token, broken webhook endpoint, failed task, or wrong repository name can stop AKS, Container Apps, or CI/CD even when the compute platform is healthy. For ACR webhook, operators should verify the current state before change, keep rollback images available, test automation paths, and record the digest, tag, trigger, run ID, or permission output that proves the release can still recover.
Performance usually appears through pull speed, build duration, automation latency, and deployment reliability rather than user-request latency. Large images, remote regions, excessive layers, broken caching, slow build tasks, or webhook delays can lengthen rollout windows. For ACR webhook, performance review should check image size, tag and digest choice, regional registry strategy, task duration, endpoint response time, and whether deployment platforms can pull the required artifact without waiting on avoidable registry or network bottlenecks.
Operational excellence means the registry is inspectable from scripts, not only from portal memory. Use Azure CLI to list repositories, show tags, inspect manifest metadata, check retention, view token and scope-map settings, run tasks, read logs, ping webhooks, and export evidence. For ACR webhook, a good runbook names the owner, intended repository path, safe command, destructive command, expected output, rollback contact, and what evidence can be saved without exposing credentials or private image details.