> For the complete documentation index, see [llms.txt](https://docs.verifone.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verifone.com/verifone-central-device-management/verifone-central/devices/registering-the-device/device-heartbeats.md). # Device heartbeats 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](/verifone-central-device-management/verifone-central/devices/view-devices.md) and [Device life cycle](/verifone-central-device-management/verifone-central/devices/registering-the-device/device-life-cycle.md) when you need the current device record and status first. ### What happens during a heartbeat Each heartbeat does two things: 1. The device reports its current state to the server. 2. 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: 1. the device sends its current identity, state, and timing information 2. the server classifies the heartbeat type 3. 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. ### 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 help the server identify device state, deliver updates, and trigger the right operational actions at the right time. ### Next steps * [Registering the device](/verifone-central-device-management/verifone-central/devices/registering-the-device.md) — understand first-contact registration * [Device life cycle](/verifone-central-device-management/verifone-central/devices/registering-the-device/device-life-cycle.md) — interpret status changes after check-in * [View devices](/verifone-central-device-management/verifone-central/devices/view-devices.md) — review last status and follow-up actions --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.verifone.com/verifone-central-device-management/verifone-central/devices/registering-the-device/device-heartbeats.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.