Core/Dash CI/CD automatic performance checks

Which deploy made it slower?

Your LCP was 2.1s two months ago. It is 2.9s now. You have deployed forty times since then. But here is the problem: the timeline alone will not tell you which deploy caused this.

That is why Core/Dash matches every visit from every real user to a specific deployment. We believe RUM Data should tell you "v2.4.1 did this" instead of "something got slower last month."

Core/Dash runs two checks around every deploy. Before deployment, Core/Dash scans your preview build and flags the pipeline if a page goes over budget. Post-deployment, every pageview is tagged with the deployment version, so each version is measured against its own real-user traffic.

The two checks catch Core Web Vitals issues at different times. The pre-deploy check is synthetic, so it sees mistakes that live in the build itself: the new hero image that is a 4MB PNG, the marketing tag that added 300KB of script to the bundle. The POSt deployment checks are pure RUM data. That tells you with certainty what a release actually does to LCP, INP and CLS.

1: Pre-deployment: synthetic checks

Core/Dash can scan a sample of your monitored page. The results gets compared to your own Core/Dash performance budgets. If a page is over, you get notified before you deploy. What you do with that notification is up to you.

To keep that check honest, Core/Dash only scores things that do not change between two runs of the same build. A Lighthouse performance score can swing ten points between two runs of the exact same page, because it is dominated by CPU timings and the machine running the audit is never the same twice. Score that in CI and you get red pipelines that mean nothing.

Add the check to your CI/CD pipeline

Create a project API key first (in the app: your project, then AI Insights, then Connect Your AI). Then add this step before your deploy job. It calls the check endpoint and takes about 30 to 45 seconds.

STATUS=$(curl -sS -o gate.json -w '%{http_code}' -X POST "https://app.coredash.app/api/project/releases/check" \
  -H "Authorization: Bearer $COREDASH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"tag":"v1.2.3","origin":"https://preview.example.app"}')

if [ "$STATUS" != "200" ]; then
  echo "CoreDash check failed to run (HTTP $STATUS): $(cat gate.json)" >&2
  exit 0
fi

VERDICT=$(jq -r '.data.check.status' gate.json)
echo "CoreDash: $VERDICT"

# if [ "$VERDICT" = "breach" ]; then exit 1; fi   ## uncomment to block the deploy

By default this only reports the verdict to your CI logs. Un-comment the last line to fail the build when a page is over budget.

Data schema:

The git fields are stored for deep links in the app and nothing branches on them.

What comes back

A valid request always answers HTTP 200. The results or verdict van be read from the result at data.check.status:

Note: The preview domain has to be reachable from the public internet by our servers

2: Post deployment: RUM validation

Post deployment checks and validation happens by matching the RUM data against your deployment. For us to be able to match your data to your deployment you can easily send the current deployment version to our API. 

curl -sS -X POST "https://app.coredash.app/api/project/releases/ingest" \
  -H "Authorization: Bearer $COREDASH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"tag":"v1.2.3"}'

Or fully automated in GitHub Actions, with the git ref as the version:

- name: Report release to CoreDash
  if: success()
  env:
    COREDASH_API_KEY: ${{ secrets.COREDASH_API_KEY }}
  run: |
    curl -sS -f -X POST "https://app.coredash.app/api/project/releases/ingest" \
      -H "Authorization: Bearer ${COREDASH_API_KEY}" \
      -H "Content-Type: application/json" \
      -d "{\"tag\":\"${{ github.ref_name }}\"}"

No pipeline, no problem! The CoreDash releases page has a Tag deployment form. Because this requires a manual action and cannot be automated this is not the required method.

Comparing Releases in Core/Dash

The Releases page lists the last 30 days, newest first: version, whether it came from CI or the app, deploy time, p75 per Core Web Vital, the delta against the previous release, and a live budget status.

Release detail is where the two halves actually meet. The pre-deploy check sits on top, one row per scanned page per budget line, and underneath it the release is measured against the whole site under the same filters, so you can see what the build claimed and what your users actually got on the same screen.

Performance Snapshots can draw deploy markers on the charts, released versions only.

See also: the Core/Dash API for querying this data from a script or an AI agent, alerts and notifications for the budgets these verdicts use, and installation if the tracker is not on your site yet.