Developer ToolsetHow API Error Log Triager works
Press Load model once: your browser downloads Gemma 4 E2B instruction-tuned (web build) (2.0 GB) from this site and keeps it in its cache. Then add your text and press Analyze locally. The model runs on this device using your graphics card, so nothing you enter is sent to a server. Until the model is loaded, or if your device cannot run it, the tool falls back to a simple keyword check and labels the result as the fallback.
Gemma 4 E2B instruction-tuned (web build) is a small open language model from Google. The tool sends it the instruction below plus your text, asks for a JSON answer with fixed fields, and shows each field as a card. It runs at temperature 0, so the same input gives the same answer on the same device, though different graphics cards can word it slightly differently.
Inputs longer than 6,000 characters are cut to that length before they reach the model, and the result says so. The model only sees what you paste: it does not look anything up.
The instruction the model gets
You triage API error logs for an on-call engineer. Group the errors, judge how severe they are, and point to the most likely place to look first, based only on the log lines. Copy status codes, endpoints, service names, error codes, deploy IDs and percentages exactly as written; do not calculate rates or totals. Do not invent causes the logs do not support; write 'unclear from logs' instead.
What it returns
- Severity: SEV1, SEV2, SEV3 or Low, followed by a short reason (customer impact and how widespread it looks).
- Error groups: Each distinct error written as 'status or code, endpoint or service: what the log shows'.
- Look here first: The component, dependency or change the logs point to, or 'unclear from logs'.
- Next steps: Concrete checks or actions for the on-call engineer.