Releases vergleichen

Du taggst jeden Deploy als Release und vergleichst die Metriken davor und danach. Der Guide zeigt API-Key, Release-Call aus CI/CD und Vergleich.

Setup-Zeit: 10–15 Minuten. Was du brauchst: authentifizierten fastmon-Account, Edit-Zugriff auf die CI/CD-Pipeline, eine Site, die schon Beacons empfängt.

1. API-Key erstellenCopy Anchor Link

1. Öffne in fastmon die Einstellungen deiner Organisation, dann Zugriff, und klicke Key erstellen. Ein Organisations-Key (fmo_…) gehört der Organisation und gilt weiter, wenn die Person geht, die ihn angelegt hat. (Ein persönlicher Key unter Account → Zugriff geht auch, folgt aber deiner Rolle und deinen Mitgliedschaften.)
2. Hake release:write und analytics:read an; mehr brauchen der Release-Call und die Vergleichs-Query unten nicht. Wähle ein Ablaufdatum.
3. Kopier den Wert: Er wird nur einmal angezeigt. Leg ihn im Secret-Store deines CI als FASTMON_API_KEY ab.

Eine Pipeline, die nur Releases meldet, kommt ohne die Einstellungen aus: Der CI/CD-Schnipsel auf der Application-Seite erstellt direkt dort einen release:write-Key, fragt, ob er dir oder der Organisation gehören soll, und schreibt ihn in den curl-Befehl.

Ist der Key geleakt, widerrufe ihn. Für ein frisches Secret rotierst du ihn, siehe Authentication.

2. Site-ID findenCopy Anchor Link

Öffne in fastmon die Site und geh auf Einstellungen. Kopier die Site-id (UUID v7, sieht aus wie 01HZX...). Leg sie im CI als FASTMON_SITE_ID ab.

3. Release-Call zum Deploy-Job hinzufügenCopy Anchor Link

Der Release-Call kommt ans Ende des Deploy-Jobs, nach erfolgreichem Deploy. Minimum-Payload ist nur version:

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

Mit -fsS scheitert curl bei Non-2xx-Responses und spart sich den Progress-Output. Ohne released_at setzt der Server „jetzt".

GitHub ActionsCopy Anchor Link

- name: Tag fastmon release
  if: success()
  env:
    FASTMON_API_KEY: ${{ secrets.FASTMON_API_KEY }}
    FASTMON_SITE_ID: ${{ vars.FASTMON_SITE_ID }}
  run: |
    curl -fsS https://api.fastmon.eu/sites/$FASTMON_SITE_ID/releases \
      -H "Authorization: Bearer $FASTMON_API_KEY" \
      -H "Content-Type: application/json" \
      -d "{ \"version\": \"${{ github.sha }}\" }"

GitLab CICopy Anchor Link

fastmon-release:
  stage: post-deploy
  needs: ["deploy"]
  script:
    - |
      curl -fsS https://api.fastmon.eu/sites/$FASTMON_SITE_ID/releases \
        -H "Authorization: Bearer $FASTMON_API_KEY" \
        -H "Content-Type: application/json" \
        -d "{ \"version\": \"$CI_COMMIT_SHORT_SHA\" }"

VercelCopy Anchor Link

Vercel führt keine beliebigen Post-Deploy-Commands im Build aus. Zwei Optionen:

• Deploy-Hook: Webhook-Receiver einrichten, der auf deployment.succeeded von Vercel hört und mit der SHA aus dem Payload den fastmon-Endpunkt aufruft.
• Edge-Function: kleine Cron-getriggerte Function, die die Vercel-API auf neue Deployments pollt und sie taggt.

4. Release-Eingang prüfenCopy Anchor Link

Release-Liste der Site abfragen:

curl https://api.fastmon.eu/sites/$FASTMON_SITE_ID/releases \
  -H "Authorization: Bearer $FASTMON_API_KEY"

Im data-Array sollte dein neuer Release stehen, mit der übergebenen version und seinem window: von released_at bis zum nächsten Release, höchstens 14 Tage.

5. Metriken vergleichenCopy Anchor Link

Auf jeder Metrik-Seite setzt Filter → Vergleichen → Release, gegen das davor beide Zeiträume, siehe Mit einem früheren Zeitraum vergleichen.

Per API schickst du das window des Releases aus der Release-Liste als time_range und das vorherige Release als compare_to:

curl https://api.fastmon.eu/organizations/$ORG_ID/analytics/query \
  -H "Authorization: Bearer $FASTMON_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "time_range": { "from": "2026-05-07T12:00:00Z", "to": "2026-05-08T12:00:00Z" },
    "metrics": ["lcp", "inp", "cls"],
    "aggregations": ["p75"],
    "filters": { "site_id": "01HZX..." },
    "compare_to": { "release_id": "01HZY..." }
  }'

Jede Zeile hat dann ein comparison mit denselben Metriken, und request.comparison_time_range nennt den verwendeten Zeitraum. Der Zeitraum des vorherigen Release beginnt bei seinem released_at, ist so lang wie time_range und endet früher, wenn das nächste Release oder jetzt davor liegt.

compare_to nimmt auch einen beliebigen Zeitraum { "from": …, "to": … } oder einen der Modi previous_period, previous_day, previous_week, previous_month. Das ältere compare_to_release_id ist veraltet, wird aber weiter bedient.

Was gut aussiehtCopy Anchor Link

• Jeder erfolgreiche Deploy taggt automatisch einen Release.
• Die Release-Version führt auf einen Commit zurück: Git-SHA, Tag oder Build-Nummer.
• Im CI gibt's einen Schritt, der den Deploy scheitern lässt, wenn der Release-Call hängt.

Häufige StolperfallenCopy Anchor Link

• Ein Release ohne released_at setzt „jetzt". Geht dein Deploy erst Minuten nach dem Job live, etwa bei Blue/Green, datier ihn zurück.
• Releases hängen an einer Site. Wer in einem Monorepo drei Sites ausliefert, braucht drei Release-Calls.
• Der Vergleich richtet sich nach der Query-Länge. Eine time_range von 7 Tagen vergleicht mit den ersten 7 Tagen des vorherigen Release. Für scharfe Regressionen halt sie kurz (1–24 h).

VerwandtCopy Anchor Link

• Releases-Konzept: was ein Release ist.
• Analytics-API: compare_to-Details.
• Notification Rules: automatisch alarmieren bei Per-Release-Regressionen.