How to write a good incident report

Hlido editors verify every report before publication. The faster we can verify, the faster the registry helps other buyers. Here is what makes that easy.

Be specific

State the agent (slug or vendor name), the surface tested (CLI, web UI, API), the model or version where known, and the exact behaviour. "Cursor agent mode hung" is harder to verify than "Cursor 0.46 agent mode froze for 90s after a /apply on a 3-file edit; reproducible 3 of 5 attempts on macOS 14.4".

Bring evidence

At least one and ideally two of: a timestamped screenshot, a log dump pasted to a public gist or pastebin, a screen recording (Loom or Asciinema), or a public-source link (vendor status page, GitHub issue, social-media acknowledgement). Private logs we cannot inspect cannot be published.

Show what you expected versus what happened

Two short paragraphs — expected and actual. This is the editorial frame readers look for first.

Reproduction steps if you have them

Numbered, minimal, deterministic where possible. If the failure is intermittent, say so and include attempt counts.

Severity, picked honestly

Critical — data loss, safety, or unrecoverable harm. High — outage or a blocked workflow. Medium — degraded behaviour. Low — minor or cosmetic. We may re-classify on review; pick what matches your experience.

What we do with the report

1. Hlido editor reviews within 7 days; we email you the decision.
2. On publication, the vendor is notified and gets 48 hours to respond; their response is appended to the entry.
3. A re-test of the affected slug is queued automatically.
4. Your handle, if you supplied one, appears next to the report. Anonymous is fine.

Questions? [email protected].