DevOps · Power BI Delivery Dashboards
Why Every DevOps Engineer Should Learn Power BI in 2026
Quick summary — why DevOps engineers should learn Power BI
DevOps engineers should learn Power BI in 2026 to turn delivery and incident data into dashboards leaders trust. Power BI connects to Azure DevOps Analytics, GitHub and Jira data, and DAX measures turn raw runs and tickets into DORA metrics: deployment frequency, lead time, change failure rate and recovery time. It complements Grafana; it does not replace system monitoring.
In this guide you will learn:
- Where Power BI fits — delivery metrics versus live system monitoring.
- Connecting DevOps data — Azure DevOps OData, GitHub API and Jira exports.
- DORA and MTTR measures — DAX formulas for the four key metrics.
- Dashboard templates — layout, data model and refresh checklist.
- Interview questions — how to talk about metrics in DevOps interviews.
SECTION 01Where Power BI fits in DevOps work
First, an honest point: Power BI is not a standard requirement in most DevOps job descriptions. Tools like Prometheus, Grafana, Datadog and CloudWatch handle live system monitoring — CPU, latency, error rates updated every few seconds — and they do that job better than a business intelligence tool. If you are choosing between learning Grafana and Power BI for an ops role, learn Grafana first.
Where Power BI earns its place is one level up: delivery and reliability performance over weeks and months. Are we deploying more often than last quarter? How long do changes take from commit to production? What share of deployments cause incidents? How quickly do we recover? These questions mix pipeline runs, repository data and incident tickets, and they are read by engineering managers and leadership who often already use Power BI. A DevOps engineer who can build that view is genuinely useful.
| Question | Better tool | Why | Typical refresh |
|---|---|---|---|
| Is the API slow right now? | Grafana / CloudWatch | Live time-series, alerting | Seconds |
| Did error rate spike after the deploy? | Grafana / APM tool | High-resolution metrics | Seconds to minutes |
| Are we deploying more often this quarter? | Power BI | Joins pipeline data over months | Daily or hourly |
| Is MTTR improving for high-severity incidents? | Power BI | Combines tickets, severity, teams | Daily or hourly |
STAR SCHEMA FOR A DEVOPS DASHBOARD
Fact tables
Deployments : DeployId, Service, Environment, DeployTime,
FirstCommitTime, Status, CausedIncident (TRUE/FALSE)
Incidents : IncidentId, Service, Severity, StartTime,
ResolvedTime, LinkedDeployId
PipelineRuns : RunId, Pipeline, Result, StartTime, DurationSec
Dimension tables
Date : Date, Week, Month, Quarter (mark as date table)
Service : Service, Team, Tier
Relationships (one-to-many, single direction)
Date[Date] -> Deployments[DeployDate]
Date[Date] -> Incidents[StartDate]
Service[Service] -> Deployments[Service]
Service[Service] -> Incidents[Service]
Date =
ADDCOLUMNS (
CALENDAR ( DATE ( 2026, 1, 1 ), DATE ( 2026, 12, 31 ) ),
"Year", YEAR ( [Date] ),
"Month", FORMAT ( [Date], "YYYY-MM" ),
"Week Start", [Date] - WEEKDAY ( [Date], 2 ) + 1,
"Quarter", "Q" & QUARTER ( [Date] )
)
// Then: Table tools > Mark as date table > choose [Date]
// Add calculated columns in fact tables:
// DeployDate = DATEVALUE ( Deployments[DeployTime] )
SECTION 02Connecting Azure DevOps, GitHub and Jira data
The hard part of any DevOps dashboard is getting clean data. Azure DevOps has the most direct route: its Analytics service exposes OData feeds for work items and pipeline runs, and Power BI Desktop can connect through the OData Feed option or the built-in Azure DevOps connector for Boards data. You sign in with your organisational account, and the Analytics views respect project permissions.
GitHub and Jira are usually reached through their REST APIs. For a public repository you can call the GitHub API directly from Power Query with Web.Contents. For private repositories and Jira, a cleaner pattern is a small scheduled script that exports runs or incidents to CSV, a database or SharePoint, which Power BI then refreshes from. That keeps API tokens out of the report file and makes refreshes reliable. Marketplace connectors also exist; check their security and support before using them at work.
| Source | Connection method | Key entity or endpoint | Watch out for |
|---|---|---|---|
| Azure DevOps Pipelines | OData Feed in Power BI | PipelineRuns entity | Filter by date to keep it fast |
| Azure DevOps Boards | Azure DevOps connector or OData | WorkItems entity | Select only needed fields |
| GitHub Actions | Web.Contents or exported CSV | /repos/{owner}/{repo}/actions/runs | Pagination and rate limits |
| Jira incidents | Exported via REST script | /rest/api/3/search/jql | API token stays in the script |
// 1) Azure DevOps pipeline runs via OData Feed
// Get Data > OData Feed, then paste a URL like:
// https://analytics.dev.azure.com/{org}/{project}/_odata/v4.0-preview/PipelineRuns?$filter=CompletedDate ge 2026-08-01T00:00:00Z&$select=PipelineRunId,RunNumber,RunOutcome,StartedDate,CompletedDate,RunDurationSeconds
// (Check the Analytics docs for the current version string.)
// 2) GitHub Actions runs for a public repo (Blank Query)
let
Source = Json.Document(
Web.Contents("https://api.github.com",
[RelativePath = "repos/OWNER/REPO/actions/runs",
Query = [per_page = "100", status = "completed"],
Headers = [Accept = "application/vnd.github+json"]])),
Runs = Table.FromList(Source[workflow_runs], Splitter.SplitByNothing()),
Expanded = Table.ExpandRecordColumn(Runs, "Column1",
{"id", "name", "conclusion", "head_branch", "created_at", "updated_at"}),
Typed = Table.TransformColumnTypes(Expanded,
{{"created_at", type datetimezone}, {"updated_at", type datetimezone}})
in
Typed
# pip install requests pandas
# Exports resolved incidents from Jira Cloud to CSV for Power BI
import os, requests, pandas as pd
base = "https://your-site.atlassian.net"
auth = (os.environ["JIRA_EMAIL"], os.environ["JIRA_API_TOKEN"])
params = {
"jql": "project = OPS AND issuetype = Incident AND resolved >= -90d",
"fields": "created,resolutiondate,priority,components",
"maxResults": 100,
}
rows, token = [], None
while True:
if token:
params["nextPageToken"] = token
r = requests.get(f"{base}/rest/api/3/search/jql", params=params, auth=auth)
r.raise_for_status()
data = r.json()
for i in data["issues"]:
f = i["fields"]
rows.append({"key": i["key"], "created": f["created"],
"resolved": f["resolutiondate"],
"priority": (f.get("priority") or {}).get("name")})
token = data.get("nextPageToken")
if not token:
break
pd.DataFrame(rows).to_csv("incidents.csv", index=False)
SECTION 03Building DORA and MTTR measures in DAX
The DORA research programme popularised four key delivery metrics: deployment frequency, lead time for changes, change failure rate and time to restore service, which recent DORA reports call failed deployment recovery time. Many teams also track a general MTTR across all incidents. Each one becomes a DAX measure on top of your Deployments and Incidents tables, sliced by week, service and team through the Date and Service dimensions.
Agree definitions before writing formulas. What counts as a deployment — every pipeline run, or only successful production releases? When does an incident start — first alert or ticket creation? Does a rollback count as a failure? Write these choices on the dashboard itself. A metric with a clear definition starts useful conversations; a vague one starts arguments. And present trends per team, not leaderboards of individuals, so the numbers drive improvement rather than fear.
| Metric | Definition used here | Data needed | Visual |
|---|---|---|---|
| Deployment frequency | Successful production deploys per week | Deployments: time, status, env | Weekly column chart |
| Lead time for changes | First commit to production deploy, median hours | Commit and deploy timestamps | Trend line with median |
| Change failure rate | Deploys causing an incident / all deploys | Deploy to incident link | Monthly KPI card |
| MTTR | Incident start to resolved, average minutes | Incident start and end times | Bar by severity |
Prod Deploys =
CALCULATE (
COUNTROWS ( Deployments ),
Deployments[Environment] = "production",
Deployments[Status] = "succeeded"
)
Deploys per Week =
DIVIDE ( [Prod Deploys], DISTINCTCOUNT ( 'Date'[Week Start] ) )
Lead Time (median hrs) =
MEDIANX (
FILTER ( Deployments, Deployments[Environment] = "production" ),
DATEDIFF ( Deployments[FirstCommitTime], Deployments[DeployTime], HOUR )
)
Change Failure Rate =
DIVIDE (
CALCULATE ( [Prod Deploys], Deployments[CausedIncident] = TRUE () ),
[Prod Deploys]
)
MTTR (min) =
AVERAGEX (
FILTER ( Incidents, NOT ISBLANK ( Incidents[ResolvedTime] ) ),
DATEDIFF ( Incidents[StartTime], Incidents[ResolvedTime], MINUTE )
)
MTTR Sev1 (min) =
CALCULATE ( [MTTR (min)], Incidents[Severity] = "Sev1" )
Open Incidents =
CALCULATE ( COUNTROWS ( Incidents ), ISBLANK ( Incidents[ResolvedTime] ) )
MTTR vs Last Month =
VAR cur = [MTTR (min)]
VAR prev = CALCULATE ( [MTTR (min)], DATEADD ( 'Date'[Date], -1, MONTH ) )
RETURN DIVIDE ( cur - prev, prev )
SECTION 04Templates: dashboard layout, metric definitions, refresh plan
Use these as a starting point for your first DevOps dashboard in Power BI — at work, or as a portfolio project using a public repository's GitHub Actions data.
DEVOPS DELIVERY DASHBOARD - PAGE LAYOUT
Page 1: Overview
Top row : 4 KPI cards - Deploys/week, Lead time (median),
Change failure rate, MTTR
Middle : Weekly deploy column chart + lead time trend line
Bottom : MTTR by severity (bar), open incidents (card)
Slicers : Date range, Team, Service, Environment
Page 2: Incidents
Table : Incident, service, severity, start, minutes to resolve
Chart : Incidents per week by service (stacked column)
Drill-thru : From service to its incident list
Page 3: Definitions (text box - see next tab)
METRIC DEFINITIONS (put this on the report)
Deployment : A succeeded pipeline run to the production
environment. Re-runs of the same commit count once.
Lead time : Hours from first commit in the release to the
production deploy. Median shown, not average.
Failure : A production deploy linked to a Sev1/Sev2 incident
or rolled back within 24 hours.
Incident : Starts at first alert or ticket creation, whichever
is earlier; ends when service is restored.
Owner : Platform team. Questions: #devops-metrics channel
Last reviewed: __________
REFRESH AND GOVERNANCE CHECKLIST
[ ] Data sources documented (OData URL, CSV paths, API scripts)
[ ] Export scripts scheduled before Power BI refresh time
[ ] Credentials stored in the gateway/service, not in queries
[ ] On-premises data gateway set up if sources are internal
[ ] Scheduled refresh configured within licence limits
[ ] Refresh failure email goes to a team mailbox
[ ] Row-level security if teams must see only their data
[ ] Workspace access reviewed every quarter
[ ] 'Last refreshed' timestamp visible on every page
SECTION 05Tips for DevOps engineers learning Power BI
Focus on the parts of Power BI that make DevOps data meaningful:
- Model before you visualise — a clean star schema with a date table prevents most wrong numbers.
- Use medians for durations — a few very long incidents or builds can distort averages badly.
- Publish definitions — put metric definitions on the report so nobody argues about what a number means.
- Measure teams, not people — DORA metrics are for improving systems, not ranking individual engineers.
- Practise with public data — a busy open-source repository's GitHub Actions runs make a realistic portfolio dashboard.
SECTION 06Interview Q&A — DevOps metrics and dashboards
Q1What are the DORA metrics?
They are deployment frequency, lead time for changes, change failure rate and time to restore service, now often called failed deployment recovery time. Together they measure both delivery speed and stability, so a team cannot look good by going fast while breaking things.
Q2How would you calculate change failure rate?
Divide the number of production deployments that caused a failure, such as an incident or rollback, by the total number of production deployments in the period. It requires linking incidents to the deploy that caused them, which is usually the hardest data step.
Q3Why use the median for lead time instead of the average?
Lead times are often skewed by a few changes that wait days for review or release. The median shows the typical experience and is not pulled up by those outliers, while the long tail can be shown separately.
Q4When would you use Grafana instead of Power BI?
For real-time operational monitoring and alerting on metrics such as latency, CPU and error rates. Power BI suits trend reporting that combines pipeline, ticket and team data over weeks or months for managers and stakeholders.
Q5How do you stop metrics from being gamed?
Track a balanced set, such as speed and stability together, publish clear definitions, look at team trends rather than individual rankings, and use the numbers to start improvement discussions rather than to reward or punish people.
SECTION 07Test yourself — Power BI for DevOps
Five questions. No sign-up.
0 / 5Pick an answer to see why it is right or wrong.
SECTION 08Frequently asked questions
Is Power BI useful for DevOps engineers?
Yes, for delivery and reliability reporting rather than live monitoring. Power BI can combine pipeline runs, repository activity and incident tickets into DORA metric and MTTR dashboards for managers. It is a useful extra skill, not a core DevOps requirement.
How do I connect Azure DevOps to Power BI?
In Power BI Desktop use the OData Feed option with an Azure DevOps Analytics URL, or the Azure DevOps connector for Boards data, and sign in with your organisational account. Select only needed fields and filter by date for faster refreshes.
Can Power BI show GitHub Actions data?
Yes. For public repositories, Power Query can call the GitHub REST API with Web.Contents and expand the workflow runs. For private repositories, export runs with a scheduled script to CSV or a database and connect Power BI to that file.
How do you build a DORA metrics dashboard?
Collect deployments with timestamps and status, link incidents to deployments, build a star schema with a date table, write DAX measures for deployment frequency, lead time, change failure rate and recovery time, and publish clear metric definitions with the report.
Should DevOps engineers learn Power BI or Grafana first?
Grafana first for most DevOps roles, because real-time monitoring and alerting are daily responsibilities. Add Power BI later if your organisation reports engineering performance to leadership or you want to build delivery dashboards across teams.
SECTION 09Related reads
Classroom & online · Noida
Build the DevOps pipelines behind the dashboards
Our DevOps Training Course covers Linux, Git, CI/CD pipelines, Docker, Kubernetes, infrastructure as code and monitoring with hands-on projects — in Noida, Delhi and live online.
Talk to a counsellor for current fees- CI/CD & pipeline projects
- Docker & Kubernetes labs
- Resume & mock interview support
- Weekday & weekend batches