Dashboard

What goes in a CTO dashboard in Metabase?

A CTO dashboard rolls engineering up to one page: delivery throughput, reliability, where engineering time actually goes, headcount and attrition, and cloud spend against budget. It is the board-meeting view — every card here summarizes a deeper operational dashboard like DORA or software delivery, and links down to it.

For: CTOs, VPs of engineering, and the exec team. Grain: monthly, with a live count for open incidents. Refresh: nightly is plenty — this page drives conversations, not pages.

What does a CTO dashboard look like?

Here’s the layout this guide builds. The executive summary and attention card sit at the top so the whole story fits in the first screen; delivery and reliability come next because they are the questions a board asks first; investment mix, people, and spend fill the bottom half, ending in a per-team scorecard that names where each number comes from.

CTO dashboard in Metabase showing deploys, lead time, uptime, incidents, investment mix, headcount, and cloud spend.
An example CTO dashboard in Metabase, rolling up delivery, reliability, people, and spend. Figures are illustrative.

Which cards belong on a CTO dashboard?

The eight below answer the four questions an exec review always asks: are we shipping, is it staying up, where is the time going, and what does it cost.

  • Deploys per month, with month-over-month and year-over-year comparison (trend)
  • Lead time for changes, p50 and p85 in days (line)
  • Uptime by tier-1 service, weekly (line)
  • Incidents by severity per week (stacked bar)
  • Engineering investment mix — roadmap vs. KTLO vs. support share of time (stacked percent bar)
  • Cloud spend vs. budget by month, with the budget as a goal line (line)
  • Headcount and trailing-12-month attrition (combo)
  • Team scorecard — engineers, deploys, change failure rate, open incidents, and spend per team (table)

What data does the dashboard need?

  • A deployments table with deployed_at, team, environment, and a caused_incident flag, from your CI/CD or Git host.
  • An incidents table with severity, opened_at, resolved_at, and service, plus per-service uptime rollups from your monitoring stack.
  • Issue-tracker data with an investment-bucket tag (roadmap / KTLO / support) at the epic or project level.
  • An HRIS export with monthly headcount and terminations per department, for the attrition line.
  • Normalized billing rows — invoice_month, team tag, cost — from your cloud billing exports.

How do you build it?

  1. Land the five sources in one warehouse — deploys and incidents from your delivery tooling, investment tags from the issue tracker, headcount from the HRIS, and billing exports from each cloud account.
  2. Build a monthly rollup model per domain (delivery, reliability, investment, people, spend) so every card reads a pre-aggregated table instead of raw events.
  3. Create the summary cards first — deploys trend, change failure rate, uptime, open Sev-1/2 count — and check them against the operational dashboards they summarize, so the exec page never disagrees with DORA.
  4. Add the investment mix, headcount, and spend cards, and set the budget goal line on the spend chart from finance’s number, not an average.
  5. Add filters for team, service tier, and date range, then wire each team scorecard row to the team-filtered operational dashboard so drill-down is one click.

Example card SQL

Monthly deploys, change failure rate, and lead time percentiles PostgreSQL
SELECT
date_trunc('month', d.deployed_at)                    AS month,
COUNT(*)                                              AS deploys,
ROUND(
  100.0 * COUNT(*) FILTER (WHERE d.caused_incident)
    / NULLIF(COUNT(*), 0), 1
)                                                     AS change_failure_pct,
PERCENTILE_CONT(0.5) WITHIN GROUP (
  ORDER BY EXTRACT(EPOCH FROM d.deployed_at - d.first_commit_at) / 86400
)                                                     AS lead_time_p50_days,
PERCENTILE_CONT(0.85) WITHIN GROUP (
  ORDER BY EXTRACT(EPOCH FROM d.deployed_at - d.first_commit_at) / 86400
)                                                     AS lead_time_p85_days
FROM deployments d
WHERE d.environment = 'production'
AND d.deployed_at >= date_trunc('month', now()) - interval '6 months'
GROUP BY 1
ORDER BY 1;

Metrics

Integrations

Dashboards

FAQ

What is a CTO dashboard?
A CTO dashboard is the executive rollup of engineering: delivery throughput, reliability, where engineering time goes, headcount and attrition, and infrastructure spend, all at monthly grain on one page. It is the page a CTO opens before a board meeting or a staff meeting — every number on it should be answerable with "and here is the team-level view" one click down, via dashboards like software delivery and infrastructure cost.
How is this different from a DORA dashboard?
A DORA dashboard goes deep on the four keys — deployment frequency, lead time, change failure rate, MTTR — with per-team breakdowns and benchmark bands. A CTO dashboard takes one summary card from it and spends the rest of the page on things DORA ignores: investment mix, people, and money. If you find yourself adding a third delivery chart here, move it to the DORA dashboard and link down instead — the exec page earns its keep by staying one screen tall.
How do I measure roadmap vs. KTLO investment mix?
Tag work at the epic or project level in your issue tracker — three or four buckets like roadmap, KTLO, support, and compliance are plenty — then compute each bucket's share of completed issues or story points per month. Resist per-ticket precision: engineers won't maintain it, and the trend matters more than the decimals. The honest failure mode is unclassified work; show an "untagged" slice rather than silently distributing it, because a 20% untagged share is itself a finding.
What grain should a CTO dashboard use?
Monthly, with a quarter or two of history. Weekly numbers are too noisy for the decisions made at this altitude — a hiring pause, a budget conversation, a reliability investment — and daily numbers belong on the operational dashboards a level down. The one exception is open Sev-1/2 incidents, which is a live count rather than a trend. Set the whole page's date filter to "previous 6 months" and let the operational dashboards handle anything finer.
Should a CTO dashboard show individual engineer metrics?
No. Individual commit counts, PR counts, or story points on an executive page invite gaming and poison trust the moment the dashboard is shared — and a CTO dashboard gets shared. Keep the grain at team level or above, and keep the metrics at outcome level: deploys, incidents, uptime, spend. If a team-level number looks wrong, that is a conversation with the team lead, backed by the team-level view in software delivery, not a leaderboard.
How do I get HR and finance data next to engineering data?
Land everything in one warehouse. Headcount and attrition come from your HRIS (Workday, BambooHR) via your ELT pipeline; cloud spend comes from AWS billing or Google Cloud billing exports; delivery data comes from your Git host and incident tool. Metabase then joins them in SQL or in models. The alternative — screenshotting the HR system into slides — is exactly what this dashboard replaces, so budget the pipeline work; it is usually two connectors, not a project.
Cloud spend is over budget — how do I find out why from here?
You don't, and that is by design: this page only tells you that spend crossed the budget line and which team's share moved. The "why" lives one click down in a infrastructure cost or cloud spend overview dashboard, where spend is broken down by service, account, and tag. Wire the team scorecard's rows to link there with the team pre-filtered, so the drill-down is a click rather than a Slack thread.