How incidents will be recorded
Investigating
What is affected and since when, posted as soon as we know.
Identified
The cause, and the workaround if there is one.
Monitoring
A fix is in place; we watch for recurrence.
Resolved
Timeline in UTC, impact on ingestion and recall, and follow-up actions.
Ingestion delays are reported separately from recall errors, because data sent during a delay is processed later rather than lost. Back to status.
What each entry will contain
| Field | Content |
|---|---|
| Components | Memory API, ingestion, recall, console, MCP servers or documentation |
| Window | Start and end in UTC |
| Impact | What failed or was delayed, and for which plans or regions |
| Data | Whether any accepted records were delayed, and confirmation when they were processed |
| Follow-up | Changes made to prevent recurrence |
Severity levels
- Degraded
- Requests succeed but slower than normal, or ingestion jobs are delayed.
- Partial outage
- Some requests fail, or one component (for example MCP) is unavailable.
- Major outage
- Most requests to the Memory API fail.
- Maintenance
- Planned work, announced in advance with its window.
Until monitoring is connected, report problems to support@auld.app with the requestId from the error body.