Elastic Heartbeat checks a service from the outside by making scheduled HTTP, TCP or ICMP probes and recording whether it responds as expected. It is useful for detecting when an endpoint is unreachable even if the machine hosting it still appears healthy. The probe's location determines what it can observe: a check inside a cluster may miss a broken public route. This is Elastic's monitoring agent, not the unrelated Linux-HA failover software.
Deployment and operating notes
Elastic still documents Heartbeat for ICMP, TCP and HTTP availability checks. Its Uptime application documentation separately marks that UI deprecated from Elastic Stack 8.15 and recommends Synthetic monitoring. Do not conflate a deprecated presentation app with retirement of every Heartbeat collection mechanism, or assume existing monitor data automatically appears in a new interface.
The recovered floating-IP failover instructions describe Linux-HA Heartbeat, a different project from Elastic Heartbeat. They are not instructions for configuring failover through the Elastic Beat.
Inventory monitor IDs, schedules, locations, credentials, expected responses, alert rules and data destinations before migration. Probe from locations that represent users or dependencies; a check inside the same cluster can miss a broken public ingress or DNS path. Choose simple protocol checks or browser journeys according to the failure being detected. Test one intentional outage and one content mismatch, then confirm alert delivery and recovery. Check permissions for ICMP and protect secrets used by authenticated HTTP monitors. Keep the old alerting path until equivalent coverage is demonstrated. Historical uptime claims should be based on measured checks and their coverage limits, not only a green dashboard.
Historical upstream link check · 2026-10-09
The recorded upstream address redirects to https://www.elastic.co/docs/reference/beats/heartbeat and returned HTTP 200 on 2026-10-09. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Preserved for context. Commands, versions, prices and results below reflect the original research.
Heartbeat is a lightweight daemon that you install on a remote server to periodically check the status of your services and determine whether they are available. Unlike Metricbeat, which only tells you if your servers are up or down, Heartbeat tells you whether your services are reachable.
Heartbeat is useful when you need to verify that you’re meeting your service level agreements for service uptime. It’s also useful for other scenarios, such as security use cases, when you need to verify that no one from the outside can access services on your private enterprise server.
You can configure Heartbeat to ping all DNS-resolvable IP addresses for a specified hostname. That way, you can check all services that are load-balanced to see if they are available.
When you configure Heartbeat, you specify monitors that identify the hostnames that you want to check. Each monitor runs based on the schedule that you specify. For example, you can configure one monitor to run every 10 minutes, and a different monitor to run between the hours of 9:00 and 17:00.
Heartbeat currently supports monitors for checking hosts via:
- ICMP (v4 and v6) Echo Requests. Use the icmp monitor when you simply want to check whether a service is available. This monitor requires root access.
- TCP. Use the tcp monitor to connect via TCP. You can optionally configure this monitor to verify the endpoint by sending and/or receiving a custom payload.
- HTTP. Use the http monitor to connect via HTTP. You can optionally configure this monitor to verify that the service returns the expected response, such as a specific status code, response header, or content.
Goal
When completed, the HA setup will consist of two Ubuntu 14.04 servers in an active/passive configuration. This will be accomplished by pointing a Floating IP, which is how your users will access your services or website, to point to the primary, or active, server unless a failure is detected. In the event that the Heartbeat service detects that the primary server is unavailable, the secondary server will automatically run a script to reassign the Floating IP to itself via the DigitalOcean API. Thus, subsequent network traffic to the Floating IP will be directed to your secondary server, which will act as the active server until the primary server becomes available again (at which point, the primary server will reassign the Floating IP to itself).
To achieve this goal, we will follow these steps:
- Create 2 Droplets that will receive traffic
- Create Floating IP and assign it to one of the Droplets
- Create DNS A record that points to Floating IP (optional)
- Install Heartbeat on Droplets
- Configure Heartbeat to Run Floating IP Reassignment Service
- Create Floating IP Reassignment Service
- Test failover
Prerequisites
In order to automate the Floating IP reassignment, we must use the DigitalOcean API. This means that you need to generate a Personal Access Token (PAT), which is an API token that can be used to authenticate to your DigitalOcean account, with reading and write access by following the How To Generate a Personal Access Token section of the API tutorial. Your PAT will be used in a script that will be added to both servers in your cluster, so be sure to keep it somewhere safe for reference, as it allows full access to your DigitalOcean account.
In addition to the API, this tutorial utilizes the following DigitalOcean features:
- Floating IPs
- Metadata
- User Data (Cloud-Config scripts)
Sources & further reading
Spotted something that needs another look?
Help improve this page →