Cypress Dashboard: What It Shows, What It Hides

Most teams treat the Cypress Dashboard as a pass/fail scoreboard: green means ship, red means investigate. That's leaving signal on the table. The dashboard surfaces parallelization efficiency, per-spec flakiness rates, and run-over-run duration trends — but the moment you need cross-project aggregation, custom retention, or failure correlation against deploy events, you hit a wall that Cypress Cloud wasn't designed to break through.

The problem isn't that Cypress Dashboard is bad tooling. It's that teams mistake a test-run viewer for a test analytics platform. Those are different products with different data models. Conflating them leads to dashboards that look busy but can't answer the question an engineering leader actually asks: "Is our test suite getting more or less reliable over the last 90 days, broken down by team?"

By the end of this article you'll know exactly what Cypress Dashboard exposes via its API, where its blind spots are, and how to route its data into a stack that can answer the questions it can't.

What Cypress Dashboard Actually Records (and Where the Model Ends)

Cypress Dashboard — now marketed as Cypress Cloud — stores run metadata, per-spec results, screenshot and video artifacts, and a flakiness score computed from retry outcomes within a single run. Its parallelization orchestrator assigns specs to CI agents and records wall-clock time per machine, which is genuinely useful for load-balancing. The data model is organized around a project, and within that, runs composed of specs composed of tests. That hierarchy is clean and queryable through the REST API (GET /runs, GET /instances/{instanceId}/tests).

Where the model ends: there is no native cross-project aggregation, no SQL-accessible raw store, no streaming export, and retention on the free tier caps at 90 days. The flakiness detection is limited to tests that pass on retry within the same run — it won't catch the test that fails every third run on Tuesdays because of a background job. For teams running more than one Cypress project, or needing to correlate test failures against deployment SHA or feature flags, the built-in dashboard provides almost nothing. That's not a criticism; it's a boundary you need to plan around.

Extracting Cypress Data Into a Stack That Can Actually Answer Questions

The Cypress Cloud REST API is the escape hatch. Authenticate with a bearer token, page through /runs, and pull per-test timing and status into a store you control — ClickHouse or BigQuery both work well at the volume most teams generate. The fetch below runs as a nightly GitHub Actions job and lands rows into a ClickHouse table.

# .github/workflows/cypress-ingest.yml
name: Ingest Cypress Run Data
on:
  schedule:
    - cron: "0 3 * * *"
jobs:
  ingest:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Fetch and load runs
        env:
          CYPRESS_API_KEY: ${{ secrets.CYPRESS_API_KEY }}
          CLICKHOUSE_DSN: ${{ secrets.CLICKHOUSE_DSN }}
        run: python scripts/ingest_cypress.py

# scripts/ingest_cypress.py
import os, requests, clickhouse_connect, datetime

BASE = "https://api.cypress.io/v1"
HEADERS = {"Authorization": f"Bearer {os.environ['CYPRESS_API_KEY']}"}
PROJECT_ID = "your-project-id"

client = clickhouse_connect.get_client(dsn=os.environ["CLICKHOUSE_DSN"])

resp = requests.get(f"{BASE}/projects/{PROJECT_ID}/runs", headers=HEADERS,
                    params={"perPage": 100}).json()

rows = []
for run in resp["runs"]:
    for spec in run.get("specs", []):
        for test in spec.get("tests", []):
            rows.append({
                "run_id": run["id"],
                "sha": run["commit"]["sha"],
                "branch": run["commit"]["branch"],
                "spec_file": spec["spec"]["name"],
                "test_title": " > ".join(test["titleParts"]),
                "state": test["state"],           # passed/failed/pending
                "attempts": len(test["attempts"]),
                "duration_ms": test["duration"],
                "recorded_at": run["createdAt"],
            })

client.insert("cypress_tests", rows)

Once you have rows in ClickHouse, flakiness analysis becomes a real query rather than a UI click. This finds tests that passed on retry (attempts > 1) more than twice in the last 30 days — the signal Cypress Cloud surfaces only within a single run, not historically:

SELECT
    test_title,
    countIf(state = 'passed' AND attempts > 1) AS flaky_passes,
    countIf(state = 'failed')                  AS hard_failures,
    avg(duration_ms)                           AS avg_ms
FROM cypress_tests
WHERE recorded_at >= now() - INTERVAL 30 DAY
GROUP BY test_title
HAVING flaky_passes > 2
ORDER BY flaky_passes DESC
LIMIT 20;

Wire this query into a Grafana panel pointed at your ClickHouse datasource and you have a CI failure analysis dashboard that updates on every ingest cycle. One team running ~4,000 Cypress tests across three projects reported triage time dropping from 22 minutes per failure investigation to under 5 once Slack alerts included the flaky-pass count and P95 duration alongside the failure message. For a more complete step-by-step test dashboard build that covers panel layout, alerting thresholds, and data source wiring, that guide covers the Grafana side in detail.

Where Engineers Burn Time Trusting the Wrong Numbers

Over-trusting the built-in flakiness score. Cypress Cloud marks a test flaky only when it fails then passes within the same run's retry loop. A test that fails deterministically on feature branches but passes on main never gets flagged. Engineers see a clean flakiness report and conclude the suite is stable — then spend a sprint chasing intermittent failures that were never counted. The fix is tracking attempts > 1 and cross-run failure rate in your own store, not relying on Cypress's label.

Ignoring spec-level duration drift. Cypress Dashboard shows per-run wall-clock time, but it doesn't alert when a spec's average duration climbs 40% over two weeks — the kind of slow leak that eventually breaks your parallelization budget. Teams notice only when CI minutes spike on the billing dashboard. Storing duration_ms per test historically and plotting a 7-day rolling average catches this weeks earlier. A related trap: failure clustering in flaky suites can make a slow-leak spec look like a flakiness pattern when the root cause is an external dependency degrading over time — two very different fixes.

Myths That Keep Teams Stuck in the Cypress Cloud UI

"The dashboard is the analytics layer." Cypress Cloud is a run orchestrator and artifact store with a results viewer attached. It is not an analytics platform. It has no SQL interface, no alerting engine, no cross-project aggregation, and no way to join test results against your deploy pipeline or incident timeline. Teams that treat it as the analytics layer end up exporting CSVs manually and building ad-hoc spreadsheets — which is worse than no analytics at all because it creates false confidence. The analytics layer is whatever you build on top of the API.

"High pass rate means the suite is healthy." A suite with a 97% pass rate can still be costing you two hours of engineer time per week if the 3% failures are non-deterministic and poorly triaged. Pass rate is a vanity metric without failure-velocity and mean-time-to-triage alongside it. Engineering leaders who want signal that actually drives decisions need the KPI set that connects test health to delivery outcomes — not a single percentage. Cypress Dashboard will never show you that view; you have to build it.

Cypress Dashboard is a solid run viewer and parallelization orchestrator — use it for what it is. The moment you need historical flakiness trends, cross-project aggregation, or failure correlation against deploys, pull the data via the REST API into ClickHouse or BigQuery and build the analytics layer yourself. Start with the nightly ingest job above, get the flaky-pass query running in Grafana, and set a P95 duration alert on your top 20 slowest specs. That's a week of work that pays back in every postmortem you don't have to run.

Note: This article is for informational purposes only and is not a substitute for professional advice. If you need guidance on specific situations described in this article, consider consulting a qualified professional.