Escanor
Skip to guide

Use Escanor

Deployments and updates to services

Inspect deployments to your connected services, read build and runtime logs, and use supported approval, redeploy and rollback controls.

Last updated

On this page

The Deployments page shows provider deployment activity across connected resources. Desktop/app releases are a separate product history on 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:

{"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, Incidents, Monitoring.

Need help? Contact support with a redacted error and the affected version.