Releases

A release is a named point in time on a site, usually a deploy. With releases you can ask "did LCP go up after we shipped v2.4.1?" with one API call, instead of squinting at a chart.

Why it matters

Performance regressions almost always line up with a deploy. Without release markers, you've got to remember when each deploy happened and compare by hand. With markers, the Analytics API does the before/after comparison for you in a single request.

When you'd touch it

• Every deploy. Cleanest setup: a POST /sites/{id}/releases from CI/CD after a successful deploy.
• Investigating a regression. Use the release picker in the dashboard to overlay metrics across releases.
• Rolling back. Tag the rollback as a release too; you want both transitions visible.

If you don't tag releases, nothing breaks. The dashboard still works without them. You just lose the deploy-correlation shortcut.

What's on a release

That's the whole resource. Releases are minimal on purpose; the goal is correlation, not building a deploy database.

Tagging from CI/CD

The reliable way is a step at the end of your deploy job:

curl https://api.fastmon.eu/v1/sites/$FASTMON_SITE_ID/releases \
  -H "Authorization: Bearer fm_$FASTMON_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{ \"version\": \"$DEPLOY_VERSION\", \"released_at\": \"$(date -u +%Y-%m-%dT%H:%M:%SZ)\" }"

Use whatever your CI considers a deploy version: git SHA, tag, build number. Whatever you pick, stick with it. Mixing styles makes the sort order meaningless.

Vercel

Add a deploy hook command. The VERCEL_GIT_COMMIT_SHA env var is populated automatically.

GitHub Actions

A final step in the deploy job, with ${{ github.sha }} or ${{ github.ref_name }} as the version.

GitLab CI

A release stage after the deploy stage, using $CI_COMMIT_SHA or $CI_COMMIT_TAG.

Comparing releases

Pass compare_to_release_id to the analytics query. The result includes a compare block with the same metrics computed for the window before that release.

{
  "time_range": { "from": "2026-05-07T00:00:00Z", "to": "2026-05-08T00:00:00Z" },
  "metrics": ["lcp", "inp"],
  "aggregations": ["p75"],
  "compare_to_release_id": "01HZX..."
}

The window for the "before" comparison is the same length as time_range, ending at the release's released_at. So a 24-hour post-release window is compared against the 24 hours immediately preceding the release.

Common scenarios

Continuous deploys

Ten deploys a day? Tag every single one. Volume isn't a problem. The release picker shows the most recent ones first; older ones stay queryable by ID.

Long-running release branches

Tag at the moment the new version actually reaches meaningful traffic: when you flip the feature flag, swap the canary, or move the load balancer. Don't tag on "deploy finished, nobody saw it yet."

Rollbacks

Tag the rollback as a separate release with a version like rollback-v2.4.0. The dashboard should show all three transitions: buggy release goes live, regression hits, rollback brings metrics back to baseline.

Common surprises

• released_at matters more than id. Sorting is by released_at. Back-date a release and the order will look wrong.
• Releases are per site. A monorepo shipping several sites needs one release call per site, even if the version string is identical.
• Deleting a release breaks compare_to_release_id requests that reference it. The endpoint returns 404. Metrics already rendered aren't affected.

Related

• Sites: releases live under a site.
• Analytics API: compare_to_release_id.
• Compare releases: step-by-step guide for hooking up CI/CD.