“The server’s playing up, can someone look?” is a perfectly honest ticket, and it’s also the start of a lost day. The specialist who picks it up knows nothing about your environment, so the first reply is a list of questions, the answers arrive tomorrow, and the fault has had another twenty-four hours to leave less evidence behind.
Hard faults are the ones where this matters, because they’ve often survived the obvious fixes already. What follows is a method we’d suggest for handing one over, whether you’re an internal IT team passing it up or a customer of a managed service passing it on. It isn’t a standard and it can’t promise that a cause turns up, but it makes it more likely that the person looking can start where you stopped.
Say what the fault is in four sentences
Before you collect anything, write down the symptom, the scope, the start and the change. The symptom is what a user or a system does, in words that could be tested: “the nightly export fails with the error below” beats “the export is broken”. The scope is who and what is affected and, equally useful, who and what isn’t. The start is the first time anyone noticed it, with a date and a time zone, and a note of whether that’s when it began or only when somebody looked. The change is anything altered shortly beforehand, including the small things nobody logged.
Here’s an invented illustration, to show the shape. “Since about 09:15 on Monday (UK time) three users in one office cannot save to the shared drive, and the error is the one pasted below. Colleagues in the same office, and the same three users on the VPN, are fine. A switch firmware update was done the previous Friday evening.” Four sentences, and a specialist already has a comparison to work with. If you don’t know one of the four, say so rather than guessing. An honest “unknown” saves more time than a confident wrong answer.
Capture it before anyone tidies up
Evidence has a shelf life. Some logs rotate or overwrite, a restart can clear volatile state and well-meant clean-up can remove exactly what would have explained the fault. So capture first, and capture in forms that someone else can use.
Timestamps need a time zone every time, and say whether the device clock was synchronised. Some systems record in UTC while the people reporting them think in local time, and in the UK the gap changes with the clocks, so “10:00” on its own can be one of two moments. A timestamp written with its offset from UTC, in the form RFC 3339 defines, can only mean one. Versions matter in the same way: operating system build, firmware, application version and the date of the last update, written down rather than described as “recent”.
Copy error messages verbatim, as text, including any code, rather than paraphrasing them. Logs and exports are better than screenshots wherever you can manage it. A screenshot shows one moment cropped by whoever took it, it can’t be searched and it can’t be compared with another system’s log. Keep a screenshot for what only a screenshot shows, such as a dialog box, and attach the log for the rest. Where the log is large, send the window around the fault with a little before it, and keep the full file in case it’s asked for.
If you can make the fault happen, find the smallest set of steps that does it, and say how often those steps trigger it. A fault you can reproduce can be tested again after each change, which is a real advantage. Do it after the exports are taken and record what you did, or on a copy where one exists. If you can’t reproduce it, say so and say what you tried.
The last item is easy to leave out. List what’s already been tried, in order, with the time and the result of each step, including the ones that did nothing. “Restarted the service, no change” tells the next person not to spend an hour on it. Without it, they’ll either repeat your work or wonder whether you did it.
Leave the evidence alone
Until a specialist has looked, try to leave the faulty system as it is. That means no reinstall, no log clearing, no “cleaning up” and no further changes you haven’t recorded. Each change you make muddies the picture, and several people each making a small adjustment is how a fault becomes impossible to describe.
That’s an ideal, and business pressure will sometimes win. If a restart is the only way to get people working, that’s a business decision and a reasonable one. Export what you can first, note the time and say in the handover that it happened. The aim isn’t never to touch anything. It’s that nothing changes without someone knowing.
Send the summary first, then the evidence, then the timeline
The order matters because the reader’s first minutes decide whether they understand the problem or start hunting through attachments. Lead with the four sentences above and a line on the business impact and any deadline, so it’s clear how much the fault matters and why. Follow with the evidence: versions, verbatim errors, log exports, the reproduction steps and the list of what’s been tried. Put the timeline last, as a dated list of what happened and what changed, because it’s the part that’s useful once the reader already knows what they are looking at.
Resist the urge to forward the entire email thread instead. A long thread holds the right facts mixed with every wrong turn, and someone has to read it all to extract them. A tidy summary with the thread attached for reference is far kinder, and it forces you to check your own understanding while you write it.
The questions you’ll be asked anyway
A good specialist will ask a handful of questions whatever you send, and it helps to have the answers ready. The table gives the usual ones and the reason behind each. It’s our own list, not a formal one.
| Question | Why it gets asked |
|---|---|
| What changed? | Faults can follow a change, so the answer narrows where to look first, including changes outside your team, such as a supplier or a licence renewal |
| Can you reproduce it? | A reproducible fault can be tested after every change. An intermittent one needs more logging before anyone changes anything |
| Who is affected, and who isn’t? | The difference between the two groups is often a quick route to the cause |
| Is there a workaround? | It tells the specialist how much room there is, and a workaround that works is itself evidence |
| What is the business impact, and is there a deadline? | It sets how much risk is reasonable. A fault that stops payroll on Friday is handled differently from one that irritates two people |
None of these needs a perfect answer. “We don’t know yet, and here’s how we’d find out” is a useful reply, and you can say it in the summary.
Agree access and change control before it’s needed
Access is a common place for a handover to stall, so settle it before the fault is urgent. We’d work within the access permissions and change-control arrangements you agree, and where practical we’d begin with logs, exports and read-only access, which can be enough to form a picture without touching anything. Any change to a live system would be discussed and authorised before it was made, so it helps to know in advance who can authorise it and how quickly that person can be reached.
If you’re an internal team, find out what your change process requires so the specialist’s suggestions can go through it. If you’re a customer of a managed service, check what your supplier allows an outside party to see under your ongoing support arrangement, because they may need to arrange access on your behalf. Whichever applies, give outside access the same care as any other remote access: named accounts, only what’s needed and a note of when it’s removed.
What a useful handback looks like
A good result isn’t only “fixed”. Where a cause is found, you want it described well enough that you could explain it to someone else and recognise it next time: what happened, how that was established and what evidence supports it. Where it isn’t found, you still want something real, such as what’s been ruled out, what’s known to be unaffected and what to measure next. Both are better than a vague “it seems fine”.
Any recommended change should say what it affects, how to test it and how to reverse it. Agree in the scope whether you want written findings and recommendations, and say at the start whether that means a short note, a fuller write-up or a conversation. Either way, record the outcome in your own change log, and if the fault tells you something about your monitoring or your routine network checks, add it to the list while it’s fresh.
If a fault has outlasted your usual fixes and you’re not sure your handover note says enough, talk it through with us. The four-sentence summary and your list of what’s been tried are all it takes to start.