Local demonstration

Check-in timer

A check-in keeps the window open. Start a short timer, send a heartbeat and let it expire, without connecting any release or delivery system.

Why this matters. Expiry-based controls fail safely only when renewal, lateness and recovery are defined. The timer makes those states visible.

Key terms 1

Heartbeat: A periodic signal showing that a process or person is still active; a missed heartbeat starts expiry.

Set a check-in window

Check-in window in seconds

Choose 5–300 seconds. Each heartbeat restarts the same window.

Local state

Timer is idle.

30seconds

0 heartbeats sent in this session

Set the duration, then start the timer.

This example stays in this page

Expiry changes only this demonstration’s local state. It sends no messages and releases no data. Closing or reloading the page clears the timer. Background tabs may refresh late; the remaining time is recalculated when the page becomes visible.

Design questions for a real workflow

Who can send a heartbeat, and how is that identity verified?
What happens if the device, clock or communication path fails?
How long is the grace period between a missed heartbeat and expiry, and who is told first?
Who reviews an expiry event before any irreversible action?
How is a false expiry reversed, and has that path been tested?