Have you ever made a support request and had it closed as “unable to reproduce” or found that when you went to collect more details, the problem was already gone? This is a frustrating experience for everyone involved - not just you, but also the person who’s trying to help you. Fortunately there are a few steps you can take to minimize the chance of this happening.

If the problem is with software, include:

  • Exactly what sequence of actions led to the problem. Different ways of performing the same task can produce different behaviors. For example it’s more useful to say “I selected ‘“‘Print…’”’ from the file menu,” rather than “I tried to print.”
  • Your operating system and all involved software versions.
  • The exact error message, if any. If you are running a command from a Linux/Unix command line, a program like “script” can capture this for you.
  • A screenshot, but only if the problem involves something visible, such as a distorted display or garbled information.

For web issues, provide everything that you would for software issues, plus:

  • The time stamp (including the time zone, such as UTC+8) at which the problem occurred.
  • The problem URL.
  • Whether you were logged in or not and what user you were logged in as.
  • If you came to that page through a link from another, then include the linking URL.
  • If the problem involved an online form, give the exact form input if you have it.

For network issues or if a website was completely unreachable provide:

  • The exact date, time and time zone when the issue occurred.
  • The program and protocol where the issue was first observed.

Ideally also try to include:

  • The output of ping and/or ping6 to the host or IP. IPv6 is usually used if it’s available, so pinging both will tell you whether IPv4 or IPv6 was used.
  • If the output for both ping/ping6 is something like “Network is unreachable” or “Destination Host Unreachable”, include the output of “route” or “/sbin/ip route”. Syntax varies between operating systems.
  • If you have a command named “mtr” available, include the output of “mtr -c 100 –report -n " from the first host, and "mtr -c 100 --report -n " from the second host if you have access to it. Packet loss can be asymmetric so both directions are important. If you don't have the command "mtr", try "traceroute" or "tracepath".

In addition to the above, for all issues describe anything else that you’ve already done to debug or correct the issue.

Finally, it might seem as though a screen shot is the best way to explain your problem. However a written description is almost always more useful, especially if it includes an exact error message. Text helps in several ways:

  • The visually impaired can understand and diagnose your needs.
  • It avoids attachment size limits that may prevent a screen capture from coming through.
  • It is faster to search online for similar problems.
  • It can also be automatically searched for in local databases in case other users have had similar problems.

A screen shot can’t hurt in most cases, but please make it a supplement to a complete written description.

Technical issues are not dictated by the alignment of the stars, but they are sometimes dictated by the alignment of a connector, so every little bit of information can help get your problem solved.