> 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-getting-started/verifone-central/verifone-central-device-manager/devices/registering-the-device/device-heartbeats.md). # 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](https://verifone.gitbook.io/us-core-help-center/verifone-central/verifone-central/devices/view-devices) and [Device life cycle](https://verifone.gitbook.io/us-core-help-center/verifone-central/verifone-central/devices/registering-the-device/device-life-cycle) 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. ### Diagnose missing work Check these in order when a device does not receive expected work: 1. Confirm the device appears and has the expected lifecycle state. 2. Confirm the device is still sending heartbeats. 3. 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](https://verifone.gitbook.io/us-core-help-center/verifone-central/verifone-central/devices/registering-the-device) — understand first-contact registration * [Device life cycle](https://verifone.gitbook.io/us-core-help-center/verifone-central/verifone-central/devices/registering-the-device/device-life-cycle) — interpret status changes after check-in * [View devices](https://verifone.gitbook.io/us-core-help-center/verifone-central/verifone-central/devices/view-devices) — 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.verifone.com/verifone-central-getting-started/verifone-central/verifone-central-device-manager/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 what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.