API Error Report
Drill into APIError events: how many, when, where, and most likely why.
Input
The user provides: $ARGUMENTS
This may be:
- empty or "all" — report on every APIError in the recent window (default)
- a session ID — report APIErrors for that one session only
- a window like "today" or "last 7d" — restrict the time range
- a cause filter: "rate-limit", "overload", or "context"
Data Sources
| Endpoint |
Returns |
GET /api/analytics |
event_types (total APIError count), daily_events (365d) — APIError volume and trend over time |
GET /api/events?session_id=X |
Per-session event stream — each APIError carries summary, data, and timestamp used to classify the cause |
GET /api/sessions?limit=N |
Sessions with id, model, started_at — attribute each error to a model and place it on the timeline |
Report Sections
1. Volume & Trend
From GET /api/analytics: total APIError count and its share of total_events. Use daily_events to chart APIErrors over the requested window and flag any day that spikes above the window mean.
2. Affected Sessions & Models
For each session in scope, pull GET /api/events?session_id=X and collect APIError events. Group by session_id and, via GET /api/sessions, by model. Report the top affected sessions and which model accounts for the most errors.
3. Likely Cause Classification
Inspect each error's summary/data and bucket it:
- Rate limit — mentions 429, "rate limit", "quota", or retry-after.
- Overload — mentions 529, "overloaded", or capacity.
- Context — mentions context length, token limit, or "too long" (correlate with nearby
Compaction events).
- Other — anything else; quote the
summary.
Report the count and percentage in each bucket.
4. Timeline
List the most recent APIErrors with timestamp, session_id, model, classified cause, and a one-line summary excerpt.
Output
- A Markdown table per section (volume, by model, by cause).
- Rates as percentages to 2 decimals; any currency in USD to 4 decimals.
- Cite exact
session_id, model, timestamp, and summary values — never invent a cause not supported by the payload; bucket as "Other" when unclear.
- End with the dominant cause and a concrete mitigation (e.g., back off and retry on 529, reduce context to cut context errors, slow request rate on 429).
- Read-only: only report what the API returns. If
curl cannot reach http://localhost:4820, tell the user to start the dashboard with npm start from the repo root.
1---2name: api-error-report3description: Produce a detailed report on APIError events from Agent Monitor data — counts over time, which sessions and models are affected, and the likely root cause (rate limits, overload/529, or context-window pressure) inferred from each event's summary and data payload. Use when API errors spike or when you need to explain why requests are failing.4---56# API Error Report78Drill into `APIError` events: how many, when, where, and most likely why.910## Input1112The user provides: **$ARGUMENTS**1314This may be:15- empty or "all" — report on every APIError in the recent window (default)16- a session ID — report APIErrors for that one session only17- a window like "today" or "last 7d" — restrict the time range18- a cause filter: "rate-limit", "overload", or "context"1920## Data Sources2122| Endpoint | Returns |23|----------|---------|24| `GET /api/analytics` | `event_types` (total `APIError` count), `daily_events` (365d) — APIError volume and trend over time |25| `GET /api/events?session_id=X` | Per-session event stream — each `APIError` carries `summary`, `data`, and `timestamp` used to classify the cause |26| `GET /api/sessions?limit=N` | Sessions with `id`, `model`, `started_at` — attribute each error to a model and place it on the timeline |2728## Report Sections2930### 1. Volume & Trend31From `GET /api/analytics`: total `APIError` count and its share of `total_events`. Use `daily_events` to chart APIErrors over the requested window and flag any day that spikes above the window mean.3233### 2. Affected Sessions & Models34For each session in scope, pull `GET /api/events?session_id=X` and collect `APIError` events. Group by `session_id` and, via `GET /api/sessions`, by `model`. Report the top affected sessions and which model accounts for the most errors.3536### 3. Likely Cause Classification37Inspect each error's `summary`/`data` and bucket it:38- **Rate limit** — mentions 429, "rate limit", "quota", or retry-after.39- **Overload** — mentions 529, "overloaded", or capacity.40- **Context** — mentions context length, token limit, or "too long" (correlate with nearby `Compaction` events).41- **Other** — anything else; quote the `summary`.42Report the count and percentage in each bucket.4344### 4. Timeline45List the most recent APIErrors with `timestamp`, `session_id`, `model`, classified cause, and a one-line `summary` excerpt.4647## Output4849- A Markdown table per section (volume, by model, by cause).50- Rates as percentages to 2 decimals; any currency in USD to 4 decimals.51- Cite exact `session_id`, `model`, `timestamp`, and `summary` values — never invent a cause not supported by the payload; bucket as "Other" when unclear.52- End with the dominant cause and a concrete mitigation (e.g., back off and retry on 529, reduce context to cut context errors, slow request rate on 429).53- Read-only: only report what the API returns. If `curl` cannot reach `http://localhost:4820`, tell the user to start the dashboard with `npm start` from the repo root.
hoangsonww