Tracking deployments
The Deployments page is a chronological list of release events — markers you record when a service deploys, so you can correlate them with metrics and incidents later.
Why track them here
Most incidents are caused by deployments. Having a chronological list right next to your metrics makes it easy to answer "what changed around the time this broke?".
Deployment markers appear as vertical lines on charts in Services, Metrics, and Dashboards — hover for details.
Header
- Title:
Deployments · Track releases and correlate with signals. - Refresh button top-right.
- + New Marker button — disabled when the source switcher is set to "All sources" (each marker is per-source). Pick a specific source from the scope switcher to enable it.
Results table
Columns:
| Column | Means |
|---|---|
| TIMESTAMP | When the deployment happened. |
| SOURCE | Which source the marker belongs to. |
| SERVICE | Which service deployed. |
| VERSION | Tag, commit SHA, or release name. |
| ENVIRONMENT | Free-form label (e.g., production, staging). |
| COMMIT | Short commit hash (first 7 characters), as plain text. |
| DEPLOYED BY | Who triggered it (when known). |
Empty state:
> "No deployment markers found. Create markers from the UI or via the CI/CD webhook."
Two ways to record a deployment
- Manual marker — pick a source, click + New Marker, fill the form (service, version, environment, commit, optional notes). Useful for ad-hoc deploys.
- Webhook from CI/CD — POST a JSON payload to
/api/v1/webhooks/deployfrom your CI workflow, authenticated with the source's API key. This is the one to wire up: a marker appears automatically on every deploy, with no one having to remember. See Programmatic access.
There is no GitHub App and no Git integration. Nothing reads your repository — a marker carries only the fields you send it, and the commit SHA is a string ObserveKit stores and displays, not a reference it resolves.
Working with a marker
The list is the whole feature. Rows are not clickable — there is no per-deployment detail page, no diff link, no PR link, and no automatic before/after error-rate comparison.
The only row action is delete (trash icon), and it is admin-only — the column does not render at all for other roles.
To see whether a deploy caused a problem, use the marker as a timestamp you take elsewhere: note the time, then set that range in Logs, Metrics or Services and compare either side of it. The correlation is yours to make — nothing here does it for you.
What this is not
- Not a CI/CD system. ObserveKit observes deployments; it doesn't run them.
- Not a release-notes tool. A marker records that a version shipped, not what changed in it.
- Not multi-source. Each marker belongs to one source. Aggregated cross-source views are on the roadmap.