Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.scrubbe.com/llms.txt

Use this file to discover all available pages before exploring further.

Ezra is Scrubbe’s AI reasoning engine. When you point it at an incident, it runs a four-stage pipeline — ingesting signals, forming hypotheses, mapping impact, and generating remediation options — then surfaces its findings as a structured analysis. From that analysis, you can produce a written report for either an engineering audience or a leadership audience, and feed the eventual outcome back so Ezra learns from each event. This guide walks through the full Ezra workflow: analysing an incident, reading the output, generating reports, and closing the learning loop.

​
Prerequisites

  • A valid API key with Ezra access enabled
  • An incident ticket with sufficient detail — techDescription, impactSummary, and blastRadius all improve Ezra’s output (see Manage Incidents)

​
Trigger an analysis

Submit an incident to Ezra for analysis. This initiates the four-stage reasoning pipeline. The call is asynchronous — Ezra processes the incident and stores the result for retrieval. 
curl -X POST https://api.scrubbe.io/api/v1/ezra/analyse \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "incidentId": "<incidentId>"
  }'
The response confirms the analysis has been queued and returns the incidentId as a reference key.
Trigger analysis as soon as an incident is created — Ezra can begin forming hypotheses while your team is still responding, giving you early direction on likely root causes.

​
Retrieve the analysis

Once Ezra has completed the pipeline, fetch the full analysis by incident ID. The output includes hypotheses, impact assessment, and ranked remediation options. 
curl https://api.scrubbe.io/api/v1/ezra/analysis/<incidentId> \
  -H "Authorization: Bearer <token>"
If the analysis is still processing, the response will indicate a pending state. Poll this endpoint until the status is complete.

​
List all analyses

Review all Ezra analyses across your workspace — useful for retrospectives and identifying recurring patterns. 
curl https://api.scrubbe.io/api/v1/ezra/analyses \
  -H "Authorization: Bearer <token>"

​
Generate a report

Turn an Ezra analysis into a written report tailored to your audience. Choose ENGINEER for a technical deep-dive or LEADERSHIP for an executive-level summary.
The engineer report includes technical hypotheses, root cause reasoning, system-level impact, and specific remediation steps.
curl -X POST https://api.scrubbe.io/api/v1/ezra/report \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "analysisId": "<analysisId>",
    "audience": "ENGINEER"
  }'
The analysisId comes from the analysis response, not the incidentId. Retrieve the analysis first to get the correct ID.

​
Submit an outcome

After the incident is resolved, tell Ezra what actually happened. This feedback feeds back into Ezra’s reasoning model, improving the quality of future analyses for similar incidents. 
curl -X POST https://api.scrubbe.io/api/v1/ezra/learn \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "incidentId": "<incidentId>",
    "outcome": "RESOLVED"
  }'
Outcome valueWhen to use
RESOLVEDThe incident was fully mitigated and systems returned to normal
MITIGATEDImpact was reduced but the underlying issue persists
DEGRADEDEzra’s remediations partially helped but the situation worsened
WORSENEDActions taken made the incident worse
NEUTRALThe outcome was unrelated to Ezra’s suggestions
Submitting outcomes is the single most effective way to improve Ezra’s analysis quality over time. Make it part of your post-incident checklist.

​
View learned patterns

Ezra identifies recurring patterns across incidents — similar failure modes, common root causes, and high-frequency service interactions. Use these patterns to prioritise reliability investments. 
curl https://api.scrubbe.io/api/v1/ezra/patterns \
  -H "Authorization: Bearer <token>"
1

Create the incident

Open a ticket via POST /api/v1/incident-ticket with as much technical context as available.
2

Trigger analysis

Call POST /api/v1/ezra/analyse with the incidentId immediately after creation.
3

Read the analysis

Poll GET /api/v1/ezra/analysis/:incidentId until complete, then review Ezra’s hypotheses and remediation options with your team.
4

Generate reports

Produce an ENGINEER report for the response team and a LEADERSHIP report for stakeholders via POST /api/v1/ezra/report.
5

Close the loop

After resolution, submit the outcome via POST /api/v1/ezra/learn so Ezra can incorporate the result into future reasoning.