---
title: Incidents and investigation
group: Use Escanor
order: 10
summary: Triage incidents from connected providers, examine logs and deploy evidence, and review proposed repairs before anything changes.
updated: 2026-10-06
---
Incidents gathers supported provider findings and operational alerts. Severity and status come from collected evidence. An Escanor summary helps you investigate, but the provider record and your on-call judgment still decide.

## Start an investigation

Connect the relevant monitoring and deployment sources. Open **Incidents**, filter/search by service and status, then inspect a detail page. Check when the problem started, what environment it affects and which provider reported it. Compare the incident's timestamps with recent deployments in [Activity](/docs/dashboard) and [Deployments](/docs/deployments).

Ask: “Summarize this incident using its evidence. What changed before it began? Do not modify anything.” Look for concrete references to logs, deploys or configuration. If evidence is sparse, treat a low-confidence answer as a reason to investigate further before changing anything.

## Summary behavior

The API can generate a summary from available incident evidence. When model-backed summarization is unavailable it can return an evidence-based fallback. A generated probable cause is unconfirmed. Inspect the linked issue and service state before acting.

Useful read paths are `GET /api/v1/incidents` and `GET /api/v1/incidents/{incident_id}`. A summary is requested with `POST /api/v1/incidents/{incident_id}/summary`, using a signed-in session and the active workspace context. Encode identifiers, which may contain provider-derived segments.

## Repairs and playbooks

The dashboard includes **Auto-fix**, repair missions and playbooks. Availability depends on supported providers, connected repositories, configured assistant/runtime and plan/policy. Opening a repair screen does not mean the agent can repair every incident or deploy without review.

Inspect its proposed target, branch, commands, tests and approval state. Use an isolated/staging environment where possible. Require evidence that the fix addresses the observed cause. Test the affected flow, then observe production signals after the approved release. A passing test run can still leave other failure modes unsolved.

## Recovery checklist

1. Establish the affected service/environment and keep an incident timeline.
2. Check provider connection health if data is stale or incomplete.
3. Compare logs and recent deploys; identify evidence for the suspected cause.
4. Review a bounded repair or a known-good rollback with your team's approval process.
5. Verify deployment, health and the original user-visible failure.
6. Keep monitoring and record remaining limitations.

If automated work stalls, inspect pending approvals and runtime readiness in **Automations > Runs**. Stop a run whose scope is unclear. If provider permissions fail, reconnect the intended account. Do not replace it with an unrestricted credential.

## Limitations

Escanor can only collect what its connected sources expose. Some incident types have rich detail while others contain only the provider's headline. A provider may resolve or update an issue independently of Escanor. Check the source of truth before closing your own incident. The homepage's incident animation shows an example sequence; it does not promise timing or recovery.

Related: [Monitoring](/docs/monitoring), [Automations](/docs/automations), [Permissions and approvals](/docs/permissions-approvals).