Clock drift and crash recovery
Why a wrong clock won't wrongly expire your license, and what happens when a run is interrupted.
A wrong clock won't expire a valid license
Some devices (a Raspberry Pi with no battery-backed clock, booted before it's reached the internet) start up believing it's the wrong date entirely. This doesn't falsely expire a valid license: your instance trusts the last server-signed time it received from a real heartbeat (plus how long it's been running since) over its own wall clock, whenever the two disagree.
The reverse holds too: setting the local clock backward doesn't extend a license past its real expiry. Only an actual heartbeat with the license server moves the time that matters.
A ticket stuck in "Running" after a restart
If the worker process is killed or the container restarts mid-run, the ticket doesn't stay stuck there. Its claim on that job carries a lease; once the lease expires, the next worker to start recovers it automatically. Any leftover changes are stashed, and the ticket goes back to Ready to be picked up again, with no orphan process left running in the background.
Restarting the worker is safe at any time for exactly this reason. An in-progress ticket at worst goes back to Ready. It's never left in limbo, and nothing about it is lost.
Editing a ticket while it's running, or clicking Run now twice
This is covered in The board and ticket statuses: exactly one job ever runs per ticket regardless of how many times a click fires, and an edit made mid-run shows up as drift rather than silently changing what's being worked on partway through.