Deployments

Operations → Deployments (/gravity/operations/deployments) is a tracker for deployments your own CI/CD pipeline performs - Sencai doesn’t run your build or deploy step, it records what happened so deployment history sits next to the incidents and changes it’s related to.

What a deployment record represents

A deployment record is one CI/CD run against one service: which service, which environment (development, staging, production, or preview), a version identifier, and a strategy (Blue/Green, Rolling, or Canary) if your pipeline reports one. Records are shown as a timeline, newest first, and can be filtered to a single service.

Creating and tracking deployments

Deployment records are created by your CI/CD pipeline pushing events to a dedicated webhook endpoint, authenticated with a bearer token you configure for the integration - the app’s Webhook Setup panel on this page shows the exact endpoint and an example request for your environment. Your pipeline reports:

• Status transitions - pending → in_progress/running → a terminal status (completed/success, failed, rolled_back, or cancelled)
• Duration, who deployed, and an optional deployment URL and error log

A record with a Blue/Green strategy additionally shows a live traffic-split percentage as your pipeline reports it.

Only your active organization’s deployments are shown - switch organizations in the app to see another one’s history. Use the service filter dropdown above the timeline to narrow a busy history down to one service’s deployments.

Reading a deployment entry

Each entry in the timeline shows the service name, a status chip, an environment chip, and (if reported) a version chip and strategy badge, plus who deployed and how long it took. A failed, rolled-back, or cancelled deployment additionally shows an expandable Error Log panel with whatever detail your pipeline reported.

Actions on a deployment

Two actions are available on a deployment that isn’t yet in a terminal state:

• Switch Traffic - available for Blue/Green deployments only. This marks the deployment complete with traffic fully switched.
• Rollback - available on any non-terminal deployment. This marks the deployment as rolled back.

Note

Both actions update Sencai’s own record of the deployment - they don’t reach into your infrastructure and perform the actual traffic switch or rollback themselves. The real action happens in your CI/CD pipeline or infrastructure; use these buttons to keep Sencai’s record accurate once you’ve done it (or to record that your pipeline already did).

A deployment linked to a change request shows that link, so you can trace a production change back to the review that approved it.

Related, lighter-weight screens

Two related screens live nearby in the sidebar:

• Chaos Engineering (/gravity/operations/chaos) lets you define and track game-day fault scenarios - target service, fault type (pod kill, CPU stress, latency injection, and similar), intensity, and duration - with a draft → running → completed lifecycle. Fault injection itself is limited to a fleet-enrolled agent, off by default, and excludes network-partition and pod-kill scenario types. Treat most scenario types as something you run and observe yourself, with Sencai recording the exercise and its outcome, rather than something the platform executes end-to-end for you today.
• UAT Sessions (/gravity/qa/uat) is a lightweight feedback tracker for dogfooding/user- acceptance sessions - star ratings, usability/performance scores, and bugs found per feature area - with an aggregate dashboard. It’s a feedback log, not a formal test-case management tool.

What’s next

• Change requests - the review/approval flow a deployment can link back to
• Incidents - root-cause candidates include recent deploys
• DevTools: CI - the CI/CD side that produces the events this page tracks
• API: Webhooks - the general webhook mechanism this integration is built on