> For the complete documentation index, see [llms.txt](https://docs.spectralink.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.spectralink.net/amie-advanced/metrics-reference/battery-health-distribution.md).

# Battery Health Distribution

How your batteries are spread across three health bands, based on how much of their original capacity they still hold.

## How it's calculated

Each battery reports its current full-charge capacity as a percentage of the capacity it had when new. That percentage places it in one of three bands:

| Band                 | Capacity remaining         |
| -------------------- | -------------------------- |
| **Good (≥80%)**      | 80% or more                |
| **Warning (65-79%)** | 65% or more, but under 80% |
| **Replace (<65%)**   | Below 65%                  |

The bands are counts of batteries, not percentages.

## What's included and excluded

* **Included:** every battery in the selected group that has reported a capacity reading.
* **Excluded:** batteries that have not yet reported one.

{% hint style="warning" %}
TODO: Batteries are matched to your selection differently from devices. Confirm what a reader sees when a group has devices but the chart shows nothing.
{% endhint %}

{% hint style="warning" %}
Because unreported batteries are excluded from all three bands, **the three counts do not always add up to Managed Batteries**. Neither the chart nor its legend shows how many were left out. If the bands total less than your battery count, the difference is batteries with no capacity reading.
{% endhint %}

{% hint style="warning" %}
TODO: How long does a battery typically go without reporting a capacity reading, and is a persistent gap a sign of a problem worth acting on?
{% endhint %}

## Time window and timezone

None. Each battery is placed using the capacity reading held against it, whenever that was taken. A battery that has not been seen for months is still counted in whichever band its reading puts it in.

## Data freshness

Calculated when the screen loads, from a read-only copy of the database.

## Filters and breakdowns

The group selector in the header narrows this chart. The three bands themselves are fixed and cannot be adjusted, and there are no other breakdowns.

## Edge cases

* **Health is not charge.** This metric is about capacity loss over the battery's life. A battery can be at 100% charge and still fall in **Replace (<65%)**.
* **A stale reading still counts.** Nothing excludes batteries whose reading is old, so the distribution can reflect batteries that are no longer in service.
* **The band boundaries are inclusive at the bottom.** A battery at exactly 80% is **Good**; at exactly 65% it is **Warning**.

## Where you'll see it

* [Dashboard](/amie-advanced/using-the-platform/dashboard.md) — as the **Battery Health Distribution** chart
* [Batteries](/amie-advanced/using-the-platform/batteries-overview.md) — as the **Health Distribution** chart, alongside a **Replace Now** card counting the **Replace (<65%)** band

## Related metrics

* [Managed Devices](/amie-advanced/metrics-reference/managed-devices.md): the device-side equivalent of **Managed Batteries**.


---

# 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.spectralink.net/amie-advanced/metrics-reference/battery-health-distribution.md?ask=<question>&goal=<user_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.