48.3k Log in Get started
Overview · Analytics

What is software delivery analytics, and how do you build it in Metabase?

Software delivery analytics turns the activity in your engineering tools — issue trackers, source control, CI/CD, incident, and support systems — into shared metrics about how work flows from idea to production. In Metabase, you build it by syncing those tools into a database, modeling a small set of clean tables, and standing up dashboards anyone can read.

TL;DR — Pick the questions leaders actually ask (Are we shipping faster? Where does work stall? Is quality slipping?), sync the source tools into a warehouse, model a thin layer, and define each metric once. Metabase reads SQL databases — it has no native connectors to tools like Linear or Jira, so a sync step always comes first.

What does software delivery analytics measure?

It measures flow, throughput, and quality across the delivery lifecycle, not individual output. The durable, leader-friendly questions are:

  • Are we delivering faster or slower over time? (lead time, cycle time)
  • How much are we shipping, and is it stable? (throughput, carryover)
  • Where does work get stuck? (time in status, WIP, backlog aging)
  • Is quality holding up? (bug aging, bug inflow vs. resolution, reopen rate)
  • Are commitments realistic? (scope change, estimation accuracy)

Avoid vanity metrics (raw commit counts, lines of code, per-person leaderboards). They're easy to game and rarely change a decision.

Which data sources feed delivery analytics?

Source categoryExamplesWhat it contributes
Issue tracking / PMLinear, Jira, Shortcut, Azure Boards, GitHub IssuesIssues, cycles/sprints, statuses, throughput, backlog
Source controlGitHub, GitLab, BitbucketPR cycle time, review latency, merge frequency
CI/CDJenkins, CircleCI, Buildkite, Azure Pipelines, GitHub ActionsBuild/deploy frequency, duration, failure rate, flaky tests
Feature flagsLaunchDarkly, StatsigRollout activity, flag debt, experiment outcomes
IncidentPagerDuty, incident.ioMTTR, incident frequency, change-failure signal
SupportZendesk, IntercomCustomer-reported bugs, support load

Most teams start with issue tracking because it covers flow, throughput, backlog, and quality in one place. See the issue tracking overview for the shared model.

Which metrics matter most?

Define each one once and reuse the definition everywhere:

  • Lead time — created → done. Captures total wait, including backlog.
  • Cycle time — started → done. Active working time; report medians, not averages.
  • Throughput — items completed per period. Pair counts with estimate points.
  • Backlog aging — how long open work has been waiting.
  • Bug aging — how long defects stay open, especially high-priority.
  • Carryover & scope change — commitment realism (needs cycle/sprint history).
  • DORA metrics — deployment frequency, lead time for changes, change failure rate, and time to restore (MTTR) from deploy and incident data.
  • Pipeline health — build success rate, pipeline duration, and flaky test rate from CI run data.

How do you connect your tools to Metabase?

Metabase reads from SQL databases, not SaaS APIs, so connecting any source tool comes down to one thing: run a pipeline that syncs the tool into a database on a schedule, then point Metabase at it. Use a managed connector (Airbyte, Fivetran) where one exists, or a free, code-based sync with dlt or the tool's API — then model it and build durable dashboards. Tool-specific setup lives on the integration pages: Linear, Jira, Shortcut, Bitbucket, Azure DevOps, Jenkins, CircleCI, Buildkite, LaunchDarkly, and Statsig.

Once the data lands, you can also point an AI assistant at Metabase's MCP server for quick, exploratory lookups. Treat that as ad-hoc exploration, not governed reporting — it keeps no history on its own.

Which dashboards should you build first?

Common mistakes

Reporting off raw connector tables.→ Model a thin clean layer first.
Cross-team output leaderboards.→ Measure flow and trends, not individuals.
Averages for durations.→ Lead/cycle time are right-skewed; use median and p90.
History-dependent metrics without history.→ Carryover, scope change, and time-in-status need change events — caveat them otherwise.

Integrations

Linear + MetabaseIssue trackingJira + MetabaseIssue trackingGitHub + MetabaseSoftware deliveryGitLab + MetabaseSoftware deliveryBitbucket + MetabaseSoftware deliveryAzure DevOps + MetabaseSoftware deliveryJenkins + MetabaseCI/CDCircleCI + MetabaseCI/CDBuildkite + MetabaseCI/CDShortcut + MetabaseIssue trackingLaunchDarkly + MetabaseFeature flagsStatsig + MetabaseExperimentationIssue tracking overviewOverviewObservability analyticsOverview

Dashboards

Software delivery dashboardSprint health dashboardCI pipeline health dashboardCode review health dashboardFeature flag rollout dashboardRelease quality dashboardIncident response dashboard

Metrics

DORA metrics overviewDeployment frequencyTime to restore (MTTR)Lead timeCycle timeBuild success ratePipeline durationFlaky test rate

FAQ

What is software delivery analytics?
Software delivery analytics is the practice of turning activity in your engineering tools — issue trackers, source control, CI/CD, incident, and support systems — into shared metrics about how work flows from idea to production. It measures flow, throughput, and quality rather than individual output. In Metabase, you build it by syncing tools like Linear, Jira, and GitHub into a SQL database, modeling a small set of clean tables, and standing up dashboards anyone can read.
Does Metabase connect natively to Linear or Jira?
No — Metabase reads SQL databases and warehouses, not SaaS APIs, so a sync step always comes first. Run a pipeline that syncs the tool into a database on a schedule — a managed connector like Airbyte or Fivetran, or a free code-based sync with dlt or the tool's API — then point Metabase at that database. Tool-specific setup lives on the Linear and Jira pages, with the shared model on the issue tracking overview.
What's the difference between lead time and cycle time?
Lead time runs from created to done, so it includes backlog wait — the requester's experience of how long work takes. Cycle time runs from started to done — the team's active working time. Both are right-skewed, so report medians with p90 rather than averages. Cycle time needs a status-change history to compute accurately; lead time works from created and completed timestamps alone, which makes it the easier starting point.
Which metrics should software delivery analytics track?
Start with flow and throughput: lead time, cycle time, and items completed per period. Add backlog and bug aging for quality, carryover and scope change for commitment realism, and the four DORA metrics — deployment frequency, lead time for changes, change failure rate, and MTTR — from deploy and incident data. Avoid vanity metrics like raw commit counts, lines of code, and per-person leaderboards: they're easy to game and rarely change a decision.
What is the difference between software delivery analytics and observability analytics?
Software delivery analytics measures how fast and safely you ship — issues, pull requests, pipelines, and deployments. Observability analytics measures how reliably the shipped software runs — incidents, error rates, availability, and infrastructure cost. They meet at the DORA metrics: deployment frequency and lead time for changes come from the delivery side, while change failure rate and MTTR need incident data joined to deploys.
Where should I start?
Sync your issue tracker first — it covers flow, throughput, backlog, and quality in one source. Model issues, cycles/sprints, and projects, then build the software delivery dashboard as the exec roll-up, followed by sprint health for iteration tracking. Add source control, CI/CD, and incident data later to layer in DORA metrics. Definitions matter more than volume: define each metric once and reuse it everywhere.
Can I use delivery metrics to compare teams or individual engineers?
Cross-team leaderboards and per-person rankings are the classic delivery-analytics mistake. Metrics like cycle time and throughput vary with work type, team size, and estimation habits, so rankings mislead and invite gaming. Measure flow and trends within a team over time instead: is cycle time improving, is throughput stable, is bug inflow falling? The same rule applies to DORA metrics — compare a team against its own trend, not against other teams.