Monitoring and Alerts: Deliver the Right Event Once

A doorbell is useful only if the right person hears it

An alert needs a meaningful condition, a recipient who can act, enough context, and a response path. Sending every build event to everyone produces noise, not observability.

Separate application telemetry from DevOps platform events. App requests, dependencies, and resource metrics describe runtime behavior. Workflow completions, approvals, and failed jobs describe the delivery system. They can be correlated, but they are not automatically stored in one table.

Choose the event closest to the question

Question	Appropriate starting signal
Did this build finish unsuccessfully?	Build/run completion and result
Is a stage waiting for approval?	Approval/stage event, not only final build completion
Is a deployment healthy?	Deployment result plus target telemetry
Did an Actions workflow fail?	Run conclusion and failed job/step logs
Has our event receiver stopped working?	Receiver health plus source/destination freshness

Azure DevOps subscriptions and service hooks support filtered events. GitHub workflow notifications and workflow_run webhooks expose their own lifecycle details. For a completed GitHub run, inspect its conclusion; “completed” does not mean “succeeded.”

Design an ingestion path explicitly

A possible custom integration is:

Azure DevOps service hook or GitHub webhook
 -> authenticated/validated receiver
 -> normalize and deduplicate
 -> Logs Ingestion API + data collection rule
 -> Log Analytics custom table
 -> query/workbook/alert

This is an architectural pattern, not a preconfigured built-in connector or a claim that every DevOps event automatically appears in Azure Monitor. Use a supported native integration when it fits; a custom receiver brings hosting, access, retry, and maintenance responsibilities.

For GitHub webhooks, validate the documented signature and limit event subscriptions. For Azure DevOps, use the service hook’s supported authentication and receiver protections. Keep credentials and full payloads out of public logs.

The Logs Ingestion API uses a data collection rule to route/transform JSON into the target schema. Plan field names and types before implementing a query. Useful normalized fields might include source, repository/project, run ID, commit, event time, conclusion, and delivery ID.

Prove data reached the right table

An HTTP success from the receiver proves only that request’s handling. It does not prove a usable row arrived in the intended Log Analytics table.

Verify:

The source delivery identifies the expected event.
The receiver accepted and validated it.
The ingestion response succeeded for the intended rule/stream.
A destination query finds the correct run ID and timestamp.
A repeated delivery does not become duplicate operational incidents.

Allow for documented ingestion latency, but do not turn an empty query into a permanent “probably syncing” explanation. Inspect schema, time range, destination, and permissions.

Turn a query into an actionable alert

First run the query interactively against real events. Define the condition, evaluation window, dimensions, and missing-data behavior. An example policy could alert when production deployment failures exceed an agreed threshold, grouped by service.

Use an Azure Monitor action group to route the resulting alert to the intended response mechanism. Test the audience with a clearly labeled sandbox event. Do not send synthetic production incident messages to real on-call recipients without agreement.

Use deduplication and suppression thoughtfully. Suppressing every repeated event can hide a new failure; alerting on every retry can overwhelm the responder. Retain the source run link and a concise next action.

Monitor the monitor

Track failed receiver deliveries, ingestion errors, and freshness. A chart showing no failures can mean either a healthy fleet or a broken event pipeline.

For GitHub, inspect the run visualization and job logs before relying on an AI summary. For Azure Pipelines, inspect the corresponding timeline and task result. Log access can expose source paths, headers, or secrets; grant only the needed audience and set retention deliberately.

Knowledge Check

A webhook receiver returned HTTP 200, but an operational dashboard is empty. What proves end-to-end ingestion?

Try it: trace one harmless event

Prerequisites: read access to sandbox delivery logs and, optionally, a sandbox Log Analytics integration. Ingestion, receiver hosting, and alert evaluations can incur charges.

Pick a real harmless sandbox run. Follow its source event through the receiver/ingestion records and query the destination by run ID. If you have no integration, draft its schema and verification checklist instead; do not label it deployed.

Expected observation: a specific event can be linked across the entire path, or the exact unimplemented/unverified boundary is named.

Cleanup: disable only exercise notifications and remove temporary rules/receivers you created. Do not delete shared operational telemetry.

Question

Why monitor telemetry freshness?

Click or press Enter to reveal answer

Decision check: notify on every run?

Prefer actionable failures or approval needs for push notifications. Use dashboards for ordinary activity, and preserve a route to raw evidence for investigation.