Change events

A change event tells GreenSlope "something in production changed at this moment". We overlay change events on every chart in the product so you can see, at a glance, whether a spike correlates with a deploy.

What counts as a change

A change event has three required fields:

• Kind — deploy, rollback, config, or flag_flip.
• Timestamp — when the change took effect.
• Release ID — the greenslope.release.id that was live after the change.

Everything else — author, PR number, environment name, description — is optional but recommended.

Sources in V1

In V1, GreenSlope accepts change events from three sources:

1. GitHub Actions / other CI — via the REST API. This is the recommended path for most teams.
2. Vercel — via the Vercel integration's deploy webhook. Zero config if you're on Vercel.
3. Direct REST calls — for custom deploy systems.

Publishing from GitHub Actions

The simplest path is a POST in your deploy workflow:

# .github/workflows/deploy.yml
- name: Record GreenSlope change event
  run: |
    curl -fsS -X POST https://api.greenslope.io/v1/changes \
      -H "Authorization: Bearer $GREENSLOPE_API_KEY" \
      -H "Content-Type: application/json" \
      -d '{
        "kind": "deploy",
        "release_id": "${{ github.sha }}",
        "environment": "production",
        "service": "web",
        "actor": "${{ github.actor }}",
        "pr": ${{ github.event.pull_request.number || null }}
      }'
  env:
    GREENSLOPE_API_KEY: ${{ secrets.GREENSLOPE_API_KEY }}

Run this after your deploy has gone live — not before. If the deploy fails and you already posted the change event, the dashboard will blame the failed commit for any unrelated spike.

Publishing from Vercel

Enable the Vercel integration once and every Vercel deploy becomes a change event automatically. See Vercel integration.

What the product does with change events

Three things:

1. Timeline overlay. Every chart shows change events as vertical markers. Hover for details; click to open the release view.
2. Regression detection. If error rate or burn rate crosses a threshold within the window after a change event, it's tagged as a suspected regression and routed to the incident loop.
3. Rollback suggestion. If the new release is worse than the previous one on your chosen SLO, the Doctor page suggests the rollback target with a deep-link to Vercel.

When to use kind: config and kind: flag_flip

deploy is for code changes. Use config for non-code production changes that can introduce risk:

• Schema migrations
• Secret rotations
• Load balancer reconfigurations
• Feature flag rollouts to new cohorts

Use flag_flip specifically when a single feature flag changes state. It's a separate kind because flag flips often need to be correlated as a group — "did this week's flag rollout correlate with the spike?".