Device heartbeats
Understand how devices check in and how the server responds.
Use this page to understand how devices check in after registration.
Device heartbeats keep the device connected to the server and ready for management tasks.
Each heartbeat sends a status signal to Verifone Central - Device Management. The server classifies the heartbeat and returns the right management plan for the device.
A management plan is the list of actions the device should perform. It can include uploads, downloads, or device actions.
When to use this page
Use this page when you need to:
understand what happens after a device checks in
interpret registration, alive, or maintenance behavior
troubleshoot why a device is not receiving expected work
Before you start
Confirm that you know:
whether the device already completed registration
whether you are checking first contact, normal connectivity, or update delivery
which device status you expect to see in the current workflow
Use View devices and Device life cycle when you need the current device record and status first.
What happens during a heartbeat
Each heartbeat does two things:
The device reports its current state to the server.
The server returns the next work for that device.
That work can include file transfers, operational tasks, or no action at all.
Heartbeat flow
Use this sequence to understand what happens on each check-in:
the device sends its current identity, state, and timing information
the server classifies the heartbeat type
the server returns the management plan for that specific device state
What a management plan can include
Depending on the heartbeat type, the server can instruct the device to:
upload diagnostic data, logs, or event details
download software, content, or other files
perform actions such as rebooting or deleting files
If no action is needed, the plan can return without a new task.
Heartbeat types
The server classifies each heartbeat into one of these types:
Registration
This is the first heartbeat sent by the device.
It starts the registration flow and creates the initial device relationship with the server.
Use this heartbeat to create the device record when auto-registration is enabled.
Expected outcome:
the device appears in the estate
the record moves into the next lifecycle state
Alive
This heartbeat occurs outside the device maintenance window.
It confirms that the device is online and connected.
Use it to verify ongoing connectivity between scheduled maintenance periods.
Expected outcome:
the device stays reachable
the server can continue tracking its current state
Maintenance
This heartbeat occurs during the device maintenance window.
The server checks whether software or content updates are available and sends the appropriate management plan.
Use this heartbeat when the device is expected to receive scheduled updates or background actions.
Expected outcome:
the device receives any pending scheduled work
rollout or maintenance actions can proceed
How heartbeat type affects work delivery
Use these checks when you expect a task to reach the device:
Registration usually creates the first managed relationship
Alive confirms normal communication, but may not be the main update window
Maintenance is the most common time for scheduled download and install work
If a rollout did not reach the device, check whether the maintenance window and current lifecycle state match the rollout plan.
How to verify heartbeat behavior
Check these expectations:
a new device starts with a Registration heartbeat
a healthy managed device continues sending Alive heartbeats
updates and planned actions are usually delivered during Maintenance heartbeats
If the observed behavior does not match the expected stage, review registration status and device lifecycle state.
Diagnose missing work
Check these in order when a device does not receive expected work:
Confirm the device appears and has the expected lifecycle state.
Confirm the device is still sending heartbeats.
Confirm the rollout aligns with the maintenance window.
If the device checks in outside its maintenance window, rollout work can remain pending until the next maintenance heartbeat.
Common problems to check
Use these checks to narrow the issue:
The device never appears — confirm whether registration was expected and whether auto-registration is allowed
The device is present but receives no work — confirm whether the current heartbeat is inside the maintenance window
Rollout work stays pending — confirm the device is still checking in and the rollout was scheduled correctly
The device looks inactive — review lifecycle state and last heartbeat timing together
Result
Heartbeats identify device state, deliver scheduled work, and confirm ongoing connectivity. Review the heartbeat type with lifecycle state before escalating a delayed rollout.
Next steps
Registering the device — understand first-contact registration
Device life cycle — interpret status changes after check-in
View devices — review last status and follow-up actions
Last updated
Was this helpful?