PhraseryPhrasery homeGet Phrasery
Documentation21 categories

Build a troubleshooting page from real failures

The same three problems keep arriving in your support inbox.

Longtroubleshootingsupportwriting
Write a troubleshooting page for the product below.

Organise by **symptom as the user describes it**, not by internal cause. Use their words as the heading, including the exact error text where there is one, so search finds it.

For each symptom:
- What the user sees
- The two or three causes, most common first
- A check that distinguishes them, with the exact command or place to look
- The fix for each
- What to do if none of it worked, including exactly what to include in a bug report

Rules:
- No cause without a check the user can actually run.
- Where a problem is genuinely our bug, say so and link the issue rather than describing a workaround as if it were the intended flow.
- Put the single most common issue first, not the most interesting one.

Product and known failures:

Making it yours

  • Paste your own material where the prompt asks for it. Everything above that line is instruction, not content.
  • Delete any rule that does not apply to you. A shorter prompt that fits beats a thorough one that does not.
  • If the answer comes back vague, add a line saying what you do not want. Constraints work better than encouragement.

Runbooks and support. What to do at 3am, the failures that keep arriving, and the limits nobody wrote down.

Related prompts

Keep this one

Phrasery saves prompts with a right-click and puts them back the same way. Add this to your own library in one click.

Add to your browser โ€” free