Azure DevOps deployment audit log: who deployed what, and when

Sooner or later someone asks: "What is on UAT right now, who put it there, and which ticket was it for?" Or after an incident: "Which branch went to staging on Tuesday afternoon?" Azure DevOps records most of the raw facts, but they live in different places and rarely line up with the ticket that prompted the deployment.

This guide covers what Azure DevOps already records, where the gaps are, and how to get a single deployment log with ticket, branch, environment, and person in one row.

What a useful deployment log answers

• What: which branch, and which work item it was for.
• Where: which environment, such as staging, UAT, or production.
• Who: the person who triggered it, not just a service account.
• When: when it was requested and when it finished.
• Outcome: whether the run succeeded, failed, or was cancelled.

What Azure DevOps records natively

Pipeline run history

Every pipeline keeps a run list with the source branch, the user who queued it (requested for), timestamps, and the result. It is the most complete raw record, and you can query it from the CLI:

az pipelines runs list \
  --org https://dev.azure.com/YOUR_ORG \
  --project "YOUR_PROJECT" \
  --pipeline-ids 42 \
  --query "[].{id:id, branch:sourceBranch, by:requestedFor.displayName, result:result, finished:finishTime}" \
  --output table

The gap: a run knows its branch, but not which ticket the deployment was for or which environment it targeted, unless your pipeline passes and records those values itself. If one pipeline deploys to several environments, the run list does not say which.

Environment deployment history

YAML deployment jobs that target an Azure Pipelines environment appear under Pipelines → Environments, with the run, commits, and associated work items for each deployment. This is the closest native view to "what is on staging".

The gap: it only covers pipelines that use deployment jobs against named environments, and work items appear through commit associations rather than as the ticket someone chose to deploy.

Organisation auditing

Azure DevOps auditing (Organization settings → Auditing) records security and configuration events, such as permission changes, policy changes, and pipeline settings changes. It is the right place to answer "who changed the pipeline's permissions", but it is not designed as a day-to-day deployment history.

Work item Development and Deployment sections

Work items can show linked builds and, where configured, deployment status. This is useful on a single ticket but does not give you a timeline across tickets and environments.

Building your own log

Teams that need a joined-up view usually do one of these:

• Pass the work item ID and environment into every deployment run as variables, and write them to a log or tag the run.
• Export run history on a schedule with the REST API and join it to work items in a spreadsheet or BI tool.
• Use classic Release pipelines, which keep release and approval history per stage.

All of these work, but each needs every deploy path to follow the convention. A deploy queued by hand without the work item ID breaks the trail.

The BranchDeploy Pro audit log

Because BranchDeploy starts every deployment from a work item, it knows the ticket, the resolved branch, the target environment, and who confirmed it at the moment the run is queued. With Pro, each deployment becomes a row in the audit log on your account page:

• Records are kept for 90 days and can be filtered by environment, status, or source.
• Run status is updated from Azure DevOps when you save a PAT with Build (Read) access; without one, records stay at queued.
• Deployments from the work item button are recorded once the extension is connected to your BranchDeploy account with a connection token. Teams and MCP deployments are recorded automatically.

The log complements Azure Pipelines run history rather than replacing it: the run link in each record takes you to the full logs. See the audit log documentation for setup.

Frequently asked questions

Does Azure DevOps have a deployment audit log?

Not as a single view. Pipeline run history, environment deployment history, and organisation auditing each cover part of it. Joining them to the ticket and environment usually takes conventions in your pipelines or a tool built for it.

How do I see who deployed to an environment in Azure DevOps?

For YAML deployment jobs, open Pipelines → Environments, choose the environment, and open a deployment to see its run and who requested it. For other pipelines, check the run's requested for user in the run history.

Does BranchDeploy log deployments made directly in Azure Pipelines?

No. It records what goes through BranchDeploy: deployments from the work item button and the AI assistant integration, and requests approved through the Teams bot. Runs queued directly in Azure Pipelines stay in Azure Pipelines run history.

Is the audit log on the free plan?

No, the audit log is part of BranchDeploy Pro. The free plan includes the work item deploy button for one project and one environment. See pricing.