Support & operations · Practical guide

Check the public delivery of a rollback, not only its source

The original deployment is restored, yet some visitors continue receiving the faulty response from a cache layer.

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 the hosting owner to distinguish restored origin content from cached public responses. Record the affected addresses and any available cache evidence, then apply the site's controlled invalidation approach if appropriate. Test through fresh external requests and a returning session rather than relying only on the restoration operator's browser. The incident remains partly unresolved until the agreed public sample receives the corrected behaviour or the remaining scope is clearly communicated.

A worked example

Illustrative example

Illustrative test: Independent fresh requests receive the restored page instead of the earlier cached failure. After a rollback, the restored source may be correct while a public delivery layer still serves an earlier error for one guide. The hosting owner compares those responses and applies the approved refresh or expiry plan. Independent fresh requests and a returning session are checked afterwards. The incident record keeps any remaining public scope visible, avoiding repeated identical deployments that do not address the layer actually supplying the stale response.

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 restored version may be correct at the host while some visitors still receive a saved faulty response from a delivery layer. Ask the hosting owner to compare the restored source with the public responses for the affected addresses. They should apply the site's approved refresh or expiry approach where needed, then check fresh external requests and a returning session. Repeatedly publishing the same files may not address that saved-copy condition. Keep any remaining affected scope visible in the incident record. The practice's recovery decision should reflect what its visitors now receive, not solely what the restoration operator sees in a privileged or unusually fresh browser.

How to check the result

The public recovery evidence covers the delivery layer visitors actually use.

A mistake to avoid

Repeatedly redeploying identical files may not address the cache condition.

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.