---
title: Deployments and updates to services
group: Use Escanor
order: 8
summary: Inspect deployments to your connected services, read build and runtime logs, and use supported approval, redeploy and rollback controls.
updated: 2026-10-06
---
The **Deployments** page shows provider deployment activity across connected resources. Desktop/app releases are a separate product history on [Releases](/releases).

## Prerequisites and first check

Connect the deployment provider and select the right workspace. Open **Deployments**, search/filter the list, and inspect the project, commit, environment, status and timestamps of a row. Compare it with the provider's own deployment page. Pending, building, failed and ready describe deployment state. A ready deployment can still have broken application workflows.

## Diagnose a failed deployment

Open the detail view and read build logs from the first error. Check runtime logs if the build succeeded but startup or requests fail. In a supported project view, the deployment panels expose build logs, runtime logs and function information.

Ask the assistant a bounded question: “Explain this staging deployment failure using its logs. List the likely cause and evidence; do not redeploy.” Treat the answer as a hypothesis and verify it against logs and configuration. Do not send secret environment values to explain a build error.

## Approvals and changes

Some operational entries provide approve/reject controls; supported project deployments provide redeploy, cancel or delete. Availability depends on provider, workspace permissions and record type. A visible button does not mean every member can modify the deployment.

Review the action's exact target and impact. After approving/redeploying, inspect the new provider deployment and test the service URL. If a request times out, inspect existing activity before retrying to avoid duplicate deployments.

## Rollback

Rollback controls operate only on supported connected services. Identify the known-good revision first, compare configuration/data compatibility, and review the requested operation. Some actions have a dry-run path; keep it enabled until the proposed change has been checked. A rollback does not restore a database backup.

Keep your provider's direct recovery path available if the Escanor connection is unhealthy. Do not turn off authentication or switch to a broader account to bypass a denied action.

## Developer reference

Authenticated overview routes include `GET /deployments`, `GET /deployments/{deployment_id}`, and approval/rejection routes. For supported projects use `GET /projects/{project_id}/deployments` and the nested deployment detail/build-log/runtime-log paths. Paths are relative to `https://api.escanor.in/api/v1` and need your session plus workspace context.

A rollback body has `service_slug`, `target_sha` and `dry_run` (default `true`). This sample proposes a rollback; with `dry_run` set to `true` it does not change production:

```json
{"service_slug":"YOUR_SERVICE_ID","target_sha":"KNOWN_GOOD_COMMIT","dry_run":true}
```

Take identifiers from your own data; do not guess them. Inspect the response's success/error state as well as its HTTP status.

## Verification and recovery

1. Confirm the provider accepted the intended action.
2. Check build/startup state and the deployed revision.
3. Test the affected user flow and monitor errors/latency.
4. Record the outcome in activity or your team's change record.

If logs are absent, check provider permissions and the time range. If the service is down, use its existing incident/runbook process. Related: [Projects](/docs/projects), [Incidents](/docs/incidents), [Monitoring](/docs/monitoring).