Skip to main content
A release is one version of one service in one environment. Squasher builds releases from deployment records and from the service.version that your telemetry sends. The Releases API lists them and compares the health of one release with the release before it. See Services and releases for how Squasher finds releases.

Operations

Both operations need the deployments:read and errors:read scopes.

Query parameters

releases.list takes these parameters. releases.get takes none. The window is at most 90 days. A release is in the list when it served at any time in the window.

Release IDs

A release ID starts with rel_. The same environment, service, and version always give the same ID, so you can store an ID and read the release again later. Treat the ID as opaque text.

List releases

Read one release

The JSON is shortened. previous_release has the same fields as a list item, and series has one point for each bucket of the compared window. serving lists each time the release served, oldest first.

Serving and rollbacks

One release of a service and environment serves at a time.
  • A release serves from its start until another release starts. A release keeps one ID: when an older version comes back (a rollback), it serves again and serving gets one more item.
  • A deployment record of an older version after a newer one started is a rollback.
  • Without a record, Squasher takes a rollback when the serving version stops sending telemetry for 15 minutes or more while an older version keeps sending. The older version serves again from the end of those 15 minutes, the first time the rollback is known.
  • When two versions overlap (a canary, a rolling deploy, or blue/green), the version that started later serves from its start. Version text does not set the order. At the same start time, a version with a deployment record wins, then the version seen last.

Health comparison

Squasher compares a release with the release of the same service and environment that served before it:
  • Squasher compares the first time the release served with the time just before it, when the previous release served.
  • Both windows have the same length: the shorter of the two serving times, and 24 hours at most. No window goes past a serving time.
  • When that length is less than 5 minutes, or there is no previous release, comparison is insufficient_data and previous is null. window is then the release’s own serving time.
  • Each side needs at least 50 requests. With fewer, comparison is insufficient_data.
regressed wins when one metric gets worse and another gets better. deltas.error_rate_points is in percentage points. deltas.p95_percent and deltas.throughput_percent are in percent. new_issues counts the issues of the service, in the same environment, that were first seen in the compared window. It lists the 10 newest and counts up to 100. Issues without a service are not counted. The metrics cover the service and environment over time, not one version. During a rolling deploy, both versions serve at the same time, so the first minutes mix both versions.

Errors

TypeScript client, CLI, and MCP

Add --json to print the full response. In MCP Code Mode, call search("releases") first, then execute with releases.list or releases.get.