Support & operations · Practical guide

Do not close an intermittent fault after one successful attempt

A page works when support checks it, so the incident is dismissed despite repeated failures under specific conditions.

Healthcare website support desk with a system checklist, telephone and orange notebook.
Know who to call and what help your support arrangement includes.

What to change

Ask for a bounded comparison that includes the reported failing conditions and a working control. Record frequency cautiously and preserve request identifiers or safe diagnostic evidence when available. The next step may be improved observation rather than immediate code changes. Agree what evidence would justify closure, including a representative period or number of controlled attempts appropriate to the issue. A single success proves only that one attempt worked.

A worked example

Illustrative example

Illustrative test: The same harmless route is checked under the reported condition and an unaffected control. A fault may occur only after returning to a partly completed form on a particular device. Support's fresh-page attempt works, so the team agrees a bounded comparison covering both conditions. Safe observations are retained and closure depends on the relevant evidence, not one successful retry. If the issue remains intermittent, the record states that uncertainty and the next observation plan rather than claiming the original reports were disproved.

Healthcare website maintenance with infrastructure, a status panel, tools and an operational checklist.
Monitor the useful journey, not just whether a server responds.
Healthcare backup and recovery illustrated by storage copies, an archive folder and a restoration route.
Test whether a backup can restore a usable service.

What this means for your practice

A page working during support's first check does not disprove repeated failures under other conditions. Ask the supplier to compare the reported failing situation with a working control and record the result cautiously. Useful context may include a particular device, route or stage of the task. Safe diagnostic identifiers can help where available. Agree what bounded set of observations would justify closure or further escalation. The next step may be better evidence rather than an immediate code change. Repeatedly retrying until success can hide unreliability, while claiming a precise failure rate from a few reports can overstate what is known. Keep the remaining uncertainty explicit.

How to check the result

The conclusion reflects observed reproducibility and clearly states remaining uncertainty.

A mistake to avoid

Repeatedly retrying until success can hide a reliability problem.

Turn reading into a next step

Your action checklist

Work through these checks with your team or supplier. Tick the ones you have resolved and leave unknowns open.

Checks to discuss

Record what you know, what is still missing and the answer you need from your team or supplier.

Use project decisions only, without personal, patient or confidential details. Entries stay in this page and are not submitted to Kay & Co. Copy or download before leaving; this page does not save your notes.

Further reading

These sources provide background for the topic. The practice examples and checklist are illustrative planning suggestions from Kay & Co.

Related guides

Need help with this?

Tell us what is getting in the way. Kay & Co. can help you understand the options and turn the next step into something that works for your practice.

Explore support & operations services or discuss your project.

Try the free Healthcare Digital Planner to find your starting priority.