Services and releases

Squasher finds your services and their releases in the traces and logs you already send. For each service, you see its request rate, error rate, latency, and health. For each release, you see if errors or latency got worse than in the release before it.

How Squasher finds services

A service is one service.name that sends server or consumer spans. Squasher reads the request rate, error rate, and p50, p95, and p99 latency of each service from those spans. Set OTEL_SERVICE_NAME to give each service a clear name. To see the services of a project, open the project and select Services in the sidebar, under Telemetry. Select Releases to see its releases.

Service health

Squasher sets the health of a service from its server error rate over the selected window:

Health	When
`failing`	5% or more of the requests fail.
`degraded`	1% or more, and less than 5%, fail.
`healthy`	Less than 1% of the requests fail.
`no_data`	The service sent no spans in the window.

A service also shows its operations, the services that call it (upstream), the services it calls (downstream), the databases it calls, and its releases. The default window is the last 24 hours. The longest window is 7 days.

The service map

The service map shows services and databases as nodes. An edge is a call from one service to another service, or from a service to a database. Each node and edge has a request count, an error rate, and an average latency. Squasher adds a database node for each database system that your client spans name in the db.system.name attribute, for example postgresql or redis. Most OpenTelemetry database instrumentations set this attribute.

How Squasher finds releases

A release is one version of one service in one environment. The version comes from the service.version resource attribute. The environment comes from deployment.environment.name. Each release has a confidence:

Confirmed: a deployment record with the status ready names the version. Deployment records come from connected Vercel, Railway, and GitHub providers, or from the Deployments API.
Inferred: only telemetry names the version. No deployment record matches it.

Send the version with your telemetry

Add service.version to the resource attributes of each service. With the standard OpenTelemetry variables:

export OTEL_SERVICE_NAME=checkout-api
export OTEL_RESOURCE_ATTRIBUTES=service.version=2.4.1,deployment.environment.name=production

Use a value that changes with each deploy, for example a version number or a commit SHA.

Record a deploy

To confirm a release, record the deploy from your CI/CD pipeline with deployments.create. Use the same service name, version, and environment that your telemetry sends.

curl -X POST "https://api.squasher.ai/v1/projects/$SQUASHER_PROJECT_ID/deployments" \
  -H "x-squasher-key: $SQUASHER_API_KEY" \
  -H "content-type: application/json" \
  -d '{
    "provider": "buildkite",
    "deployment_id": "build-123",
    "service": "checkout-api",
    "version": "2.4.1",
    "environment": "production",
    "status": "ready",
    "commit_sha": "9f2c1e7",
    "branch": "main",
    "finished_at": "2026-10-10T16:02:11.000Z"
  }'

The key needs the deployments:write scope. See the Deployments API.

Serving interval

A release starts at the deploy time or at its first span or log, whichever is earlier. It ends when the next release of the same service and environment starts. The release that serves now is the current release. When you roll back to an older version, that release keeps its first start time.

Release health

Squasher compares each release with the release of the same service and environment that served before it:

It takes the first 24 hours of the release. When the release served for less time, it takes the whole serving time, and at least 5 minutes.
It takes the same length of time just before the release started, while the previous release served.
It compares the error rate, the p50, p95, and p99 latency, and the requests per minute of the two windows.

Each window needs at least 50 requests. With fewer, the result is insufficient data.

Result	When
Regressed	The error rate rises by 1 percentage point or more, or p95 rises by 20% or more and 5 ms or more.
Improved	The error rate falls by 1 point or more, or p95 falls by 20% or more and 5 ms or more.
Unchanged	Neither of the above.
Insufficient data	No previous release, or fewer than 50 requests in one window.

The comparison also lists the new issues of the service that were first seen in the release window.

The numbers cover the service over time, not one version. During a rolling deploy, the old and the new version serve at the same time, so the first minutes mix both versions.

Use services and releases from the CLI and MCP

squasher services list --project <project_id> --health failing
squasher services get --project <project_id> checkout-api
squasher services map --project <project_id> --environment production
squasher releases list --project <project_id> --service checkout-api
squasher releases get --project <project_id> <release_id>

Agents can call services.list, services.get, services.map, releases.list, and releases.get through MCP Code Mode. All five are read-only.

Next steps

Services API

Read services and the service map from a script.

Releases API

Read releases and their health comparison.

Send traces with OpenTelemetry

Send spans and logs with a service name and version.

Deployments API

Record deploys from any CI/CD pipeline.

Get started

Guides

Services and releases

How Squasher finds services

Service health

The service map

How Squasher finds releases

Send the version with your telemetry

Record a deploy

Serving interval

Release health

Use services and releases from the CLI and MCP

Next steps

Services API

Releases API

Send traces with OpenTelemetry

Deployments API

​How Squasher finds services

​Service health

​The service map

​How Squasher finds releases

​Send the version with your telemetry

​Record a deploy

​Serving interval

​Release health

​Use services and releases from the CLI and MCP

​Next steps

Services API

Releases API

Send traces with OpenTelemetry

Deployments API

How Squasher finds services

Service health

The service map

How Squasher finds releases

Send the version with your telemetry

Record a deploy

Serving interval

Release health

Use services and releases from the CLI and MCP

Next steps