Deploy tracking · Docs

Most incidents start with a change. When Pulseback knows what you shipped and when, it can name the likely cause the moment something breaks.

How likely cause works

When an incident opens, Pulseback looks at changes in the same environment during the 30 minutes before it triggered. Candidates are ranked by how recent they are and how well the service name matches the failing monitor. The best match becomes the incident’s likely cause and appears on its timeline; with AI summaries on, it’s part of “What we know” too.

It’s a suggestion, labelled as one. Verify before you roll back.

GitHub

In Integrations, add a GitHub integration and choose its environment (production by default).
Copy the webhook URL:

https://app.pulseback.io/api/v1/deploys/<key>

In your GitHub repository, open Settings → Webhooks → Add webhook, paste the URL, set the content type to application/json, and choose these events:
- Deployment statuses, for teams that deploy through GitHub deployments.
- Pushes: only pushes to the default branch are recorded, for teams that deploy on merge.
- Releases, for teams that ship tagged releases.

The commit, author, message and link come from the event.

Any CI: the deploy webhook

Add a Deploy webhook integration and POST JSON to its URL at the end of a deploy:

POST https://app.pulseback.io/api/v1/deploys/<key>
Content-Type: application/json

Field	Type	Required	Notes
`service`	string	yes	What was deployed, e.g. `api`. Matched against monitor names for likely cause. Up to 120 characters.
`environment`	string	no	Defaults to the integration’s environment. Must match your monitors’ environment to be considered.
`sha`	string	no	Commit SHA, up to 64 characters.
`title`	string	no	Short description, e.g. the PR title.
`message`	string	no	Longer description or commit message, up to 2,000 characters.
`author`	string	no	Who shipped it.
`url`	string	no	Link to the commit, PR or pipeline run.
`at`	string	no	ISO-8601 time of the deploy. Defaults to when the request arrives.

It returns 202 with the recorded change’s id: { "id": "…" }.

Example

curl -fsS -X POST "https://app.pulseback.io/api/v1/deploys/$PULSEBACK_DEPLOY_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "service": "api",
    "environment": "production",
    "sha": "a3f9c12",
    "title": "Move sessions to Redis cluster",
    "author": "dana-k",
    "url": "https://github.com/acme/api/commit/a3f9c12"
  }'

GitHub Actions

- name: Tell Pulseback
  if: success()
  run: |
    curl -fsS -m 10 -X POST "https://app.pulseback.io/api/v1/deploys/${{ secrets.PULSEBACK_DEPLOY_KEY }}" \
      -H "Content-Type: application/json" \
      -d "{\"service\":\"api\",\"environment\":\"production\",\"sha\":\"${GITHUB_SHA}\",\"title\":\"${{ github.event.head_commit.message }}\",\"author\":\"${GITHUB_ACTOR}\",\"url\":\"${{ github.server_url }}/${{ github.repository }}/commit/${GITHUB_SHA}\"}"

Seeing changes

Recorded deploys show up on incident timelines when they’re the likely cause, and as markers on the response-time chart around each incident. Over the API, list them with GET /api/workspaces/:wid/changes (filter with ?environment=).