> ## Documentation Index
> Fetch the complete documentation index at: https://docs.squasher.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Services and releases
> See the health of each service, the service map with its databases, and how each release changed errors and latency.
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:
```bash theme={null}
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.
```bash theme={null}
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](/api-reference/deployments).
### 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:
1. 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.
2. It takes the same length of time just before the release started, while the previous release
served.
3. 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
```bash theme={null}
squasher services list --project --health failing
squasher services get --project checkout-api
squasher services map --project --environment production
squasher releases list --project --service checkout-api
squasher releases get --project
```
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
Read services and the service map from a script.
Read releases and their health comparison.
Send spans and logs with a service name and version.
Record deploys from any CI/CD pipeline.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.