Owner-reported findings. Published Oct 26, 2026. Reviewed Oct 26, 2026.
Why a package
A support case that starts with “it’s broken” spends its first day on questions. A case that starts with evidence gets to engineering faster. This is the generic version of the escalation SOP I use.
The package
- Symptom. What happens, in exact words. Copy error text; don’t paraphrase it.
- Timestamp. When it started, and when you saw it last. Include the time zone.
- Known-good comparison. A working unit, file, or config next to the failing one. “This one works, this one doesn’t” is worth more than a paragraph.
- What changed. Updates, moves, new devices, config edits. If nothing changed, say so.
- Repro steps. How to make it happen again, or a note that it’s intermittent and how often.
- Logs. The relevant ones, already pulled, from the time window in item 2.
- Remote access. How the vendor can get in, and who needs to approve it, arranged before they ask.
Before sending
- Strip anything the vendor doesn’t need: passwords, unrelated internal details.
- Say what you already tried, so they don’t ask you to reboot it again.
- Keep known, suspected, and unconfirmed separate.
Example
The 1969 kill date case went out in this format.