XML identifier: Defines the failed heartbeat transfer retry percentage of the heartbeat interval.
Purpose: When either logging server and/or network congestion/trouble is present, this setting will help heartbeats be successfully received by logging server.
When a heartbeat transfer fails — whether due to a network outage, DNS resolution failure, server error, or a non-200 HTTP response — the app automatically schedules a retry. Retries use exponential backoff: each
successive retry waits twice as long as the previous one, up to a maximum equal to the heartbeat interval itself. This prevents flooding the network during prolonged outages while still recovering quickly from brief glitches.
Status: In use from May 2026, starting with versions 1.1.8.x and 1.2.6.x.
Category: Single level (aka standard identifier).
Usage: Setting a percentage from 0 (meaning this functionality OFF) up to 100 (in essence also meaning OFF), this sets the basic retry interval. Note that exponential backoff is used to avoid spamming the network and/or server when not responding, meaning that first retry will be after the given percentage of the heartbeat interval, but later attempts within this interval will be exponetially longer.
Note: The retry cycle is completely independent of the regular heartbeat timer.
When the next regular heartbeat fires, any pending retry is cancelled and
the backoff counter is reset.
Default:
Defaults to 10 meaning, 10 percent of the heartbeat interval will be the first wait time before a heartbeat is retried, with exponential wait time on further retries..
Development status: Released in 1.1.8.x/1.2.6.x. Standard feature, as defined in app config.
Closer explanation, with example:
With the default of 10 % and a 300-second heartbeat interval, the retry
schedule is:
| Retry | Delay | Cumulative |
|---|---|---|
| 1st | 30 s | 0:30 |
| 2nd | 60 s | 1:30 |
| 3rd | 120 s | 3:30 |
| 4th | 240 s | capped — next regular heartbeat fires at 5:00 |
Set to 0 to disable automatic retries entirely.
| XML example: |
<!-- Retry after 5 % of the heartbeat interval (more aggressive) -->
<key>HBRetryPct</key>
<integer>5</integer>HeartbeatRetries — Payload field
When a heartbeat is successfully delivered after one or more retries, the JSON payload now includes a HeartbeatRetries field with the number of retry attempts that occurred since the last successful transfer. This field is not present when no retries were needed.
“`
“HeartbeatRetries”: “3”