Deploy markers

To mark a deploy in Clerion, add one HTTP call to the end of your deploy job: a POST to https://api.getclerion.com/api/v1/deploys with your Clerion key and your site id. The Errors page then shows each deploy with its error rate and conversion rate for the 24 hours before against the 24 hours after, and the briefing can name the deploy behind a change.

Before you start

You need two things from the dashboard:

Store the key as a secret in your CI, never in the repository. Anyone holding it can read your analytics through the MCP server.

Send the call

From any shell or CI step:

curl -X POST https://api.getclerion.com/api/v1/deploys \
  -H "Authorization: Bearer $CLERION_KEY" \
  -H "Content-Type: application/json" \
  -d '{"websiteId":"site_...","label":"v1.8"}'

The body takes three fields:

A successful call returns 200 with the deploy as recorded.

GitHub Actions

Add the key as a repository secret called CLERION_KEY, then add a last step to the job that deploys:

- name: Mark the deploy in Clerion
  if: success()
  run: |
    curl -fsS -X POST https://api.getclerion.com/api/v1/deploys \
      -H "Authorization: Bearer ${{ secrets.CLERION_KEY }}" \
      -H "Content-Type: application/json" \
      -d "{\"websiteId\":\"site_...\",\"label\":\"${GITHUB_REF_NAME} ${GITHUB_SHA::7}\"}"

if: success() keeps a failed deploy from being marked. -f makes the step fail loudly if the key is wrong, so you notice.

GitLab CI

deploy:
  script:
    - ./deploy.sh
    - >
      curl -fsS -X POST https://api.getclerion.com/api/v1/deploys
      -H "Authorization: Bearer $CLERION_KEY"
      -H "Content-Type: application/json"
      -d "{\"websiteId\":\"site_...\",\"label\":\"$CI_COMMIT_REF_NAME $CI_COMMIT_SHORT_SHA\"}"

Add CLERION_KEY as a masked CI variable.

A deploy script, marking the real time

If your deploy finishes a while after the command runs, record the time it went live:

#!/bin/sh
set -e
./release.sh
AT=$(date -u +%Y-%m-%dT%H:%M:%SZ)
curl -fsS -X POST https://api.getclerion.com/api/v1/deploys \
  -H "Authorization: Bearer $CLERION_KEY" -H "Content-Type: application/json" \
  -d "{\"websiteId\":\"site_...\",\"label\":\"$(git rev-parse --short HEAD)\",\"deployedAt\":\"$AT\"}"

From Node

await fetch("https://api.getclerion.com/api/v1/deploys", {
  method: "POST",
  headers: { Authorization: `Bearer ${process.env.CLERION_KEY}`, "Content-Type": "application/json" },
  body: JSON.stringify({ websiteId: "site_...", label: process.env.RELEASE_TAG }),
});

Other CI and hosts

Any system that can run a command after a deploy can send the same curl: GitLab CI, CircleCI, Bitbucket Pipelines, or a deploy script on your own server. Put it after the step that makes the new version live, not after the build, so the time marks when visitors started getting it.

Read the Deploys card

Open your site, go to Observability, then Errors, and scroll below the event log. Each deploy in the selected period has one row:

A change for the worse is marked in red. A deploy less than six hours old shows as still settling and is not judged, because a few hours of traffic are too few to read.

The briefing and Ask Clerion see the same rows. When a drop starts on the day of a deploy and that deploy moved errors or conversion, the briefing names it.

Limits

If the call fails

Questions

Does marking a deploy change my analytics?

No. It adds a row to the Deploys card and a fact for the briefing. Visits, events and errors are counted exactly as before.

Can I mark a deploy by hand?

Yes. The same curl from a terminal works; give it a label such as pricing page copy.

Is the key safe to put in CI?

As a CI secret, yes. It reads analytics and records deploys, and cannot change or delete anything else. If it leaks, replace it in Your model and every copy stops working.

Which deploys should I mark?

Production only. Preview and staging deploys get no real traffic, so their before and after would be empty.