brily
API reference

Releases.

A release marker is a single event that ties together what you shipped, when, and to whom. One API call from CI powers three downstream consumers: NPS cohort analysis, status page annotations, and uptime regression detection.

The Release object

{
  "id": "rel_9f3K",
  "name": "release-1.24",
  "version": "1.24.0",
  "environment": "production",
  "rollout_percent": 100,
  "started_at": "2026-04-18T12:00:00Z",
  "finished_at": "2026-04-18T12:14:00Z",
  "commit_sha": "a7f1c9e",
  "commit_url": "https://github.com/acme/app/commit/a7f1c9e",
  "description": "Checkout redesign, new search ranker.",
  "tags": ["checkout", "search"],
  "project_id": "proj_7KfD1",
  "created_at": "2026-04-18T12:00:00Z"
}

Create a release marker

POST/v0/releases

Post this from CI at deploy time. The minimum payload is name plus started_at (ISO 8601). Include the commit SHA if you can — it powers link-outs from the status page and NPS dashboard.

curl -X POST https://api.brily.app/v0/releases \
  -H "Authorization: Bearer $BRILY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "release-1.24",
    "version": "1.24.0",
    "environment": "production",
    "rollout_percent": 100,
    "started_at": "2026-04-18T12:00:00Z",
    "commit_sha": "'"$GITHUB_SHA"'",
    "commit_url": "https://github.com/acme/app/commit/'"$GITHUB_SHA"'"
  }'

GitHub Actions example

- name: Post release marker to Brily
  if: github.ref == 'refs/heads/main'
  run: |
    curl -X POST https://api.brily.app/v0/releases \
      -H "Authorization: Bearer ${{ secrets.BRILY_TOKEN }}" \
      -H "Content-Type: application/json" \
      -d '{
        "name": "release-${{ github.run_number }}",
        "environment": "production",
        "started_at": "'"$(date -u +%Y-%m-%dT%H:%M:%SZ)"'",
        "commit_sha": "${{ github.sha }}"
      }'

Update a release

PATCH/v0/releases/{id}

Common uses: bumping rollout_percent during a gradual rollout, setting finished_at when the deploy completes, adding a description after the fact.

List releases

GET/v0/releases

Query params: environment, from, to, pagination. Use this endpoint to hydrate the release picker in your own dashboards.

What release markers power

  • NPS cohort analysis— every NPS response from a user exposed to a release is tagged with that release's id. The dashboard does before/after comparisons automatically.
  • Status page annotations — releases show as markers on the 90-day uptime chart, helping visitors correlate outages with deploys.
  • Uptime regression detection — if p95 latency degrades materially in the 30 minutes after a release marker, we alert the release author automatically.

Environments

Valid environment values are strings of your choice; common ones are production, staging, canary. Only releases in the environment your monitors watch will be correlated with uptime; all environments can power NPS cohort analysis if you pass matching cohort identifiers.

Partial rollouts

For canary deploys, use rollout_percent. If your front-end sends the user's exposure flag with each NPS widget event, cohort analysis uses that flag rather than the release's nominal percent — so 10% rollouts still produce clean cohort splits.

Next
NPS API