← The archive
PRACTICAL IT

Check Monday’s scheduled work after the clock change

Use the return to GMT to check that a business schedule still matches the time its owner expects.

· 2 min read

Start with the business expectation

GOV.UK lists 25 October as the date UK clocks go back in 2026. Its guidance says the autumn change moves clocks back one hour at 2am, returning the UK to GMT. For a business IT team, this is a useful prompt to inspect a scheduled task rather than assume its displayed time means what everyone expects.

Our recommendation is to choose one important Monday job and ask its owner when the result must be available. Write the answer with a date and named time zone. “Ready before the London office opens on Monday” is a business requirement to clarify; a bare “08:00” in a configuration screen is not enough for that conversation.

Read the actual configuration

Have the responsible administrator record the schedule expression, configured time zone and next planned run shown by the service. Ask them to check the service’s current documentation for how it handles clock changes. This briefing does not claim that every scheduler treats local times or repeated hours in the same way.

For a fictional wholesale business, the operations manager expects a stock summary before the Monday morning meeting. IT records the next run shown by the reporting service and compares it with the agreed meeting time. They also ask how long preparation normally takes and whether a person needs time to check the result. The example is a proposed review, not a report of a production test.

Avoid creating a second delivery while investigating

Before clicking a manual-run button, inspect the existing run history and any queued work. Agree who may authorise a retry and how the team will establish whether the earlier attempt already delivered its output. Do not treat a confusing timestamp as permission to send another customer message or repeat a financial operation.

If a correction is needed, record the intended behaviour and use the normal change process. Test with an approved non-production task where available. Keep the previous configuration in the change record and give one person responsibility for checking the next real result.

Check the result at the agreed time

On Monday, compare the actual delivery time with the business expectation. Where the service presents both local and UTC timestamps, record which representation you used. Keep any original timestamp and its zone with the evidence rather than copying an unexplained number into a ticket.

Close the check with a specific outcome: the selected job produced its expected result by the agreed time, or an identified issue has an owner. Expand to other critical schedules according to their impact. This is a practical operations review, not a reason to move every schedule or change system clocks manually.

Sources

Practical suggestions in this article are editorial recommendations. The source supports the guidance attributed to it.

Something needs correcting?

Get in touch to explain which claim needs attention and share the supporting source.