# How to Send Azure DevOps Build Success Alerts to Your Team's Phones

> Use an Azure DevOps Build completed service hook and a saved PingRoom webhook message to send one selected pipeline success to a shared Room.

- Published: 2026-10-25
- Author: PingRoom
- Category: Automation
- Topics: Azure DevOps pipeline notifications, Azure DevOps service hook webhook, build succeeded notification, automation notifications to phone
- Canonical: https://pingroom.io/blog/azure-devops-build-success-push-notifications
- Cover image: https://pingroom.io/blog/azure-devops-build-success-push-notifications-cover.webp
- Cover description: Two PingRoom avatars guide a clay build token toward a receiving tray while Pingo watches beside a closed folio.

**To send one selected Azure DevOps build success to a small team's phones, create a `Build completed` Web Hooks subscription, filter it to one pipeline definition and `Succeeded`, send no resource or message details, and point it at a PingRoom incoming webhook with a fixed saved title and message.** Azure DevOps remains the source of truth for the build.

This is a webhook recipe, not a native Azure DevOps integration. The Azure DevOps setup needs project-administrator or project-collection-administrator permission, and the Room owner needs **PingRoom Pro**.

## Decide whether a shared phone alert is the right path

[Azure DevOps notifications](https://learn.microsoft.com/en-us/azure/devops/organizations/notifications/about-notifications?view=azure-devops) already cover build activity through email and service hooks. Start there when the people who need the result already watch those destinations.

| Need                                                               | Better starting point                        |
| ------------------------------------------------------------------ | -------------------------------------------- |
| A developer needs logs, commits, artifacts, approvals, or a rerun  | Azure DevOps                                 |
| The team already watches build email or another configured service | Keep that route                              |
| People need project context and approvals on a phone               | Use an Azure DevOps-focused mobile companion |
| One selected success should reach a small shared group             | Azure DevOps service hook → PingRoom         |
| A failed build needs paging, acknowledgement, or escalation        | Keep the incident system                     |

The recipe below reports one narrow fact: a selected build definition completed with Azure DevOps status `Succeeded`. It does not prove a deployment is healthy, every dependent system is available, or every phone displayed a notification.

## Create the Room-side destination

Create or choose a private Room for the stable group that needs the completion signal. Open **Settings → Connections → From another app**, add an incoming webhook, and save fixed copy such as:

- Title: `Azure build succeeded`
- Message: `Selected pipeline completed successfully`

Then copy the complete webhook URL. The [incoming-webhook setup guide](/blog/webhook-to-push-notification) covers the Room-side controls, and the [webhook reference](/documents/webhooks) documents current fields and limits.

Treat the URL as a credential. Anyone who can read it can try to send to the Room. Limit who can edit the Azure DevOps service hook, never place the URL in source control or screenshots, and regenerate the PingRoom webhook secret if it leaks.

## Create one success-only service hook

In the Azure DevOps project that owns the pipeline:

1. Open **Project settings → Service hooks** and choose **Create subscription**.
2. Select **Web Hooks** as the service.
3. Choose the **Build completed** trigger.
4. Select the one pipeline definition that matters and set **Build status** to **Succeeded**.
5. Paste the PingRoom incoming-webhook URL as the target.
6. Set **Resource details to send** to **None**. Also choose no messages or detailed messages when the form offers those controls.
7. Use **Test**, inspect the result, and finish the subscription only when the harmless test behaves as expected.

Microsoft's [service-hook event reference](https://learn.microsoft.com/en-us/azure/devops/service-hooks/events?view=azure-devops) documents the `build.complete` event and its definition and status filters. Its [Web Hooks setup guide](https://learn.microsoft.com/en-us/azure/devops/service-hooks/services/webhooks?view=azure-devops) documents the public HTTPS requirement, permission boundary, resource-detail controls, and test action.

The privacy-minimal settings matter. Azure DevOps can send build metadata, messages, and links, but this route does not need them. PingRoom ignores unrelated top-level fields and falls back to the saved webhook title and message when its optional `title` and `message` fields are absent. The phone therefore gets the fixed completion fact, while pipeline details stay in Azure DevOps.

![Two PingRoom avatars move one sealed clay signal between a closed build box and an empty shared bowl while Pingo observes beside a credential case.](/blog/azure-devops-build-success-push-notifications-inline.webp)

At the miniature handoff bench, [Pingo](/Pingo)—PingRoom's fictional CMO—watches one sealed signal leave the closed build box. The deadpan supervision fits the boundary: Pingo cannot access the project, enter a private Room, or send anything. People configure and control both ends.

## Test the boundary with harmless work

Use a disposable or otherwise harmless pipeline run and check these cases:

1. A successful run of the selected definition produces one Room Ping with the saved title and message.
2. A failed or stopped run produces no success Ping.
3. A different pipeline definition produces no Ping.
4. The phone alert contains no project, repository, branch, commit, author, log, or URL data.
5. Repeating the same test reveals whether your Azure DevOps delivery creates a duplicate; the direct route does not claim durable event-level deduplication.

Our production check sent a representative `build.complete` body through a local mock of PingRoom's documented saved-message rules. It confirmed that unrelated Azure DevOps fields do not replace the fixed copy and that the copy fits current limits. It did not use a live Azure DevOps project, PingRoom Room, phone, or network delivery, so your harmless real run remains part of setup.

## Know when the direct route is too small

PingRoom applies the webhook's configured cooldown—five seconds by default—and accepts up to 60 calls per minute. That can absorb a brief burst, but it is not durable Azure-event deduplication. If Azure DevOps retries a completed-build delivery later, the direct route may create another Ping.

Put a relay between Azure DevOps and PingRoom when you need to authenticate the source separately, retain a stable event identity across retries, select fields from the payload, or monitor delivery. Azure DevOps Web Hooks support optional Basic authentication over HTTPS; a relay can verify that credential, validate the event, and then call PingRoom with a stable `Idempotency-Key`. Keep those deterministic checks in application code.

For broader notification design, read [how to design CI/CD deployment notifications](/blog/ci-cd-deployment-notifications). Build history, approvals, logs, rollbacks, and incident response should remain in the systems that own them. PingRoom is the short attention path.

## Send the first completion Ping

Open [PingRoom Rooms](/app/rooms), create the private destination Room, add the incoming webhook, and run one harmless successful build of the selected definition. Check Azure DevOps, the single Room event, and what a locked test phone actually shows before connecting an important pipeline.

Microsoft, Azure, and Azure DevOps are trademarks of the Microsoft group of companies. PingRoom is not affiliated with or endorsed by Microsoft.