Releases vergleichen

Deploys aus CI/CD taggen und „hat dieser Deploy LCP verschlechtert?" in einer Query beantworten.

Wenn du Performance-Regressionen sauber erwischen willst, taggst du jeden Deploy als Release, und die Analytics-API macht den Vorher-Nachher-Vergleich. Dieser Guide deckt den kompletten Ablauf ab: API-Key, Release-Call aus CI/CD, Vergleichs-Query.

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 erstellen

Öffne in fastmon die Einstellungen deiner Organisation, dann Zugriff, und klicke Key erstellen. Ein Organisations-Key (fmo_…) gehört der Organisation und gilt darum auch dann noch, wenn die Person geht, die ihn angelegt hat: die richtige Form für eine Pipeline. (Ein persönlicher Key unter Account → Zugriff geht auch, folgt aber deiner Rolle und deinen Mitgliedschaften.)
Hake release:write und analytics:read an; mehr brauchen der Release-Call und die Vergleichs-Query unten nicht. Wähle ein Ablaufdatum.
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.

Key geleakt? Widerrufe ihn. Brauchst du nur ein frisches Secret, rotiere ihn (der Nachfolger behält Name, Scopes und Ablaufdatum, mit optionalem Übergangsfenster für den Wechsel). Was ein Key darf und was nicht, steht unter Authentication (nur auf Englisch).

2. Site-ID finden

Ö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ügen

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)\"
  }"

Die -fsS-Flags lassen curl bei Non-2xx-Responses laut scheitern und unterdrücken den Progress-Output. released_at ist optional; wenn du's weglässt, setzt der Server einfach „jetzt".

GitHub Actions

- 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 CI

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\" }"

Vercel

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üfen

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.

Im Dashboard taucht er im Release-Picker der Performance-Ansicht auf.

5. Metriken vergleichen

Das Dashboard hat einen Release-Picker auf Performance: Release auswählen, Chart überlagert Vorher/Nachher. Programmatischer Vergleich: compare_to_release_id setzen:

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..."
  }'

Die Response enthält einen compare-Block mit denselben Metriken für ein gleich langes Fenster, das beim released_at des Releases endet. Beispiel oben: 24 Stunden nach dem Release vs. die 24 Stunden direkt davor.

Was gut aussieht

Jeder erfolgreiche Deploy taggt automatisch einen Release. Nichts von Hand.
Die Release-Version lässt sich auf einen Commit zurückführen: Git-SHA, Tag, Build-Nummer, was auch immer du nutzt.
Im CI gibt's einen Schritt, der den Deploy scheitern lässt, wenn der Release-Call hängt. Sonst hast du irgendwann stille Lücken und glaubst den Vergleichen nicht mehr.

Häufige Stolperfallen

Ein Release ohne released_at setzt „jetzt". Meistens passt das. Aufpassen, wenn dein Deploy-Job Minuten vor dem tatsächlichen Live-Gehen läuft (Blue/Green-Flip kommt später); dann lieber zurückdatieren.
Releases hängen an einer Site. Wer in einem Monorepo drei Sites ausliefert, braucht drei Release-Calls.
Vergleichsfenster richtet sich nach der Query-Länge. Eine 7-Tage-Query vergleicht gegen die 7 Tage davor. Wenn du Regressionen scharf sehen willst, halt das Fenster kurz (1–24 h).

Verwandt

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

Releases vergleichen

On this page