Incidents and investigation

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 and 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, Automations, Permissions and approvals.