Skip to main content
Plan requirement: This feature requires the On-call Standard plan or above. Learn more
Use a Vercel team webhook to sync deployments and production rollbacks (Instant Rollback) to Flashduty On-call. Each deployment becomes one Flashduty change; every state of the deployment, from created and built to succeeded, promoted, failed or canceled, updates that same change.
Vercel team webhooks are available to Pro and Enterprise teams only; Hobby accounts cannot configure them.

​
In Flashduty On-call

  1. In the Flashduty console, go to Integration Center → Change Events
  2. Select Vercel and enter an integration name
  3. To assign changes to specific channels, configure rules in the integration’s Routing based on labels such as project or environment
  4. Click Save and copy the generated Push URL

​
In Vercel

1

Open webhook settings

In the Vercel dashboard, switch to the target team and go to Settings → Webhooks. You need permission to manage the team’s webhooks.
2

Select events

Under Deployment Events, select:
  • Deployment Created
  • Deployment Succeeded
  • Deployment Promoted
  • Deployment Rollback
  • Deployment Error
  • Deployment Cancelled
Project, Feature Flag and Firewall events are not deployment changes; if selected, Flashduty returns success without recording a change.
3

Choose projects and enter the push URL

  1. Choose the projects to send: All Team Projects or specific projects
  2. Endpoint URL: paste the full Flashduty push URL
  3. Click Create Webhook
Vercel then shows a secret. Flashduty does not need it; requests are authenticated by the integration_key in the push URL.

​
What one change is

​
Status mapping

Done, Failed and Canceled are end states; Flashduty records the change’s end time. These deliveries return success without recording a change: event types that do not start with deployment. (Project, Feature Flag, Firewall and others); deployment events about checks or integration actions; deployment.cleanup (the deployment is permanently deleted after its retention period, which does not change its earlier result).

​
Change content

Labels can be used for routing and for filtering the change list: ref, sha and actor come from the deployment metadata of a connected GitHub, GitLab or Bitbucket repository; deployments made directly from the CLI do not have them.

​
FAQ

After a production deployment builds successfully, Vercel sends deployment.succeeded, then deployment.promoted once production traffic has switched to it. Both map to Done and update the same change.
No. Flashduty uses the time carried by the Vercel event, so the same event at the same time is recorded once. When a delivery fails, Vercel retries it for up to 24 hours.
Rolling back from the same deployment to the same deployment produces the same change key, so the second rollback updates the first rollback’s change (its last time becomes the second rollback’s time) instead of creating a new one. Vercel rollback events carry only the two deployment IDs, not a rollback ID of their own.
  • unsupported type: Flashduty received a deployment event it does not support yet (for example deployment.blocked subscribed through the API). Select only the six events listed above, or contact us
  • payload.deployment.id is missing: the payload is incomplete; make sure the request comes from a native Vercel webhook