How to Build an Internal Build Dashboard

Every game studio has a moment where someone asks, “Is the build healthy?” and nobody can answer quickly. The CI pipeline says green, but the binary is 200 MB larger than last week. Tests pass, but coverage dropped from 68% to 41% after someone deleted a test file. The crash rate is climbing, but nobody noticed because the crash reporting dashboard lives on a different screen that nobody has open. A build dashboard aggregates all of these signals into one page that answers the question in five seconds.

Choosing Your Metrics

A build dashboard should track five categories of health. Build status is the simplest: did the build compile and link successfully on every target platform? This is a binary pass/fail, but tracking it over time reveals patterns like a branch that fails every third build due to a flaky linker issue. Test results go deeper: not just pass/fail, but how many tests passed, how many failed, how many were skipped, and how long the suite took to run. A gradual increase in skipped tests is a warning sign that discipline is eroding.

Binary size is one of the most underrated metrics in game development. It creeps upward silently — a new texture atlas here, an embedded video there — until your game exceeds a platform’s size limit or blows past the psychological download-size threshold for players. Track binary size per platform (Windows, macOS, Linux, Android, iOS, console) and per configuration (debug, release, shipping). Alert when any platform’s size increases by more than a configurable percentage in a single commit.

Crash rate connects your build pipeline to your production reality. Pull the crash-free session rate from your crash reporting tool (Bugnet, Sentry, Crashlytics) for the most recent build and display it alongside the build that produced it. If a build ships with a 96% crash-free rate and the next build drops to 91%, that regression is visible immediately. Code coverage, finally, tracks how much of your codebase is exercised by automated tests. It is an imperfect metric — 100% coverage does not mean zero bugs — but a sudden drop in coverage means someone deleted or disabled tests, which always deserves investigation.

Data Sources and Ingestion

The data for your dashboard already exists. It is scattered across CI logs, API endpoints, and build artifacts. Your job is to collect it into one place. For build status and test results, most CI platforms expose an API: GitHub Actions has the Checks API, GitLab has the Pipelines API, and Jenkins has its REST API. Write a post-build script that queries this API and extracts the relevant fields.

# post_build_collect.py — runs after every CI build
import json, os, requests, sqlite3
from datetime import datetime

def collect_metrics():
    build_id = os.environ["BUILD_ID"]
    branch = os.environ["BRANCH_NAME"]

    # Test results from JUnit XML
    test_data = parse_junit_xml("build/test-results.xml")

    # Binary size from build artifacts
    sizes = {}
    for platform in ["windows", "linux", "macos"]:
        artifact = f"build/dist/{platform}/game"
        if os.path.exists(artifact):
            sizes[platform] = os.path.getsize(artifact)

    # Crash rate from Bugnet API
    crash_resp = requests.get(
        "https://api.bugnet.io/v1/projects/my-game/health",
        headers={"Authorization": f"Bearer {os.environ['BUGNET_TOKEN']}"}
    )
    crash_rate = crash_resp.json()["data"]["crash_free_rate"]

    # Store in SQLite
    db = sqlite3.connect("metrics.db")
    db.execute(
        "INSERT INTO builds VALUES (?, ?, ?, ?, ?, ?, ?)",
        (build_id, branch, datetime.utcnow().isoformat(),
         test_data["passed"], test_data["failed"],
         json.dumps(sizes), crash_rate)
    )
    db.commit()

For binary size, measure the final packaged artifact, not intermediate object files. For coverage, most test runners produce a Cobertura or LCOV report that you can parse into a single percentage. For crash rate, query your crash reporting API for the crash-free session rate of the build version that was just deployed.

Building the Web UI

The dashboard itself should be as simple as possible. A static HTML page that fetches JSON from an API endpoint is all you need. No React, no Vue, no build step. One HTML file, one CSS file, one JavaScript file that calls fetch() and renders tables and charts. Use Chart.js or a similar lightweight charting library for trend lines. Host it on your internal network or behind a VPN.

The layout should prioritize at-a-glance readability. At the top, show the most recent build for each active branch with a colored status indicator: green for healthy, yellow for warnings, red for failures. Below that, show trend charts for binary size, crash rate, and test count over the last 30 days. Each chart should have a horizontal line at the warning threshold so the team can see how close they are to triggering an alert.

Branch comparison is essential. During feature development, the team needs to see how a feature branch’s metrics compare to the main branch. If the feature branch added 15 MB to the Windows build, that information needs to be visible before the merge happens, not after. Display a diff column showing the delta between the branch’s latest build and the main branch’s latest build for each metric.

Alerting Without Alert Fatigue

Alerts are only useful if people pay attention to them. If you alert on every minor fluctuation, the team will mute the channel within a week. Define clear thresholds that represent genuinely actionable problems. Binary size increasing by more than 5% in a single commit is unusual and worth investigating. Crash-free rate dropping below 97% is a regression. Test pass rate below 95% means something is broken. Test count decreasing by more than 10 tests means someone is deleting tests, which is almost never the right solution.

Send alerts to a dedicated Slack or Discord channel that the team monitors but does not use for conversation. Include the build ID, the branch, the metric that triggered the alert, the previous value, and the current value. Link directly to the dashboard page filtered to that branch so the engineer can investigate immediately without navigating.

Historical Trends and Regression Detection

The most valuable feature of a build dashboard is not the current state but the historical trend. A single data point tells you almost nothing. A trend line over 90 days tells you everything. You can see the week where binary size started growing faster than usual. You can see the day when crash rate spiked after a specific merge. You can see the gradual erosion of test coverage as the team prioritized features over testing during a crunch period.

Store metrics indefinitely — disk is cheap, and you will want to look back six months from now when a subtle regression appears. Tag each data point with the commit hash and the branch name so you can correlate metric changes with code changes. When a metric crosses a threshold, the dashboard should show which commits were included in the build that triggered the alert, so the team can start investigating from the right place.

“A build dashboard does not make your builds healthier. It makes unhealthy builds visible before they become emergencies. The fix is still your responsibility, but at least now you know there is a fix needed.”

Extending the Dashboard Over Time

Start simple and add metrics as the team identifies new blind spots. Common additions include shader compile time (which grows with asset count and can slow iteration), asset import warnings (which indicate upcoming build failures), memory usage from automated profiling runs, and platform-specific compliance checks for console submissions. Each new metric follows the same pattern: collect it in the post-build script, store it in the database, add a chart to the dashboard, and define an alert threshold.

The dashboard becomes the team’s shared understanding of build health. When someone asks “is the build healthy?” the answer is a URL, not an opinion. That shared source of truth is worth more than any individual metric it displays.

Related Issues

For tracking game health metrics beyond the build pipeline, see how to build a game health dashboard. For automating the smoke tests that feed into your build dashboard, read how to build automated smoke tests for game builds.

The build dashboard is the scoreboard for your engineering team. Make it visible, make it honest, and make it impossible to ignore.