> 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/using-the-platform/alerts.md). # Alerts **Alerts** lists conditions the system has detected across your devices and batteries. Alerts are raised automatically — nothing needs to be configured, and you do not create them yourself. The screen is a list to monitor. It shows you what has been detected and when. ## Before you start Nothing needs to be set up. Alerts appear as conditions are detected. ## What raises an alert Two conditions raise an alert today. ### Battery Temperature Warning Raised when a battery reports a temperature **above 50°C**. The description records the temperature that triggered it, for example "Battery temperature reported as 58°C", so you can see how far past the threshold it went without opening anything else. An email is also sent when this alert is raised. ### Out of Contact Raised when a device has not checked in for **more than 7 days**. The description names the device, for example "Device 2knh15bnnih001a has not checked in for more than 7 days". {% hint style="warning" %} **A device that stays offline stops generating alerts.** This alert is only raised while a device has been silent for between 7 and 14 days. Past 14 days, no further alerts are raised for it. A long-missing device therefore disappears from new alerts rather than escalating. To find devices in that state, use the **>31 days** band on [Devices overview](/amie-advanced/using-the-platform/devices-overview.md) instead. {% endhint %} ### Repeated conditions are not repeated alerts Neither alert type will raise again for the same battery or device **within 7 days** of the last one. A battery running hot all week produces one alert, not one per reading. This keeps the list readable, but it means the number of alerts is not a measure of how often a problem occurred. ## Screen layout {% hint style="info" %} Screenshot needed: Alerts at the standard viewport, with a populated list showing more than one alert type and a range of statuses {% endhint %} A single table, with search, filters and paging. | Column | What it shows | | --------------------- | -------------------------------------------------------------------- | | **Alert Type** | Which condition was detected | | **Alert Description** | The detail of that specific occurrence, including the measured value | | **Battery Serial** | The battery involved, if any. Select it to open that battery | | **Device Serial** | The device involved, if any | | **Status** | Where the alert has reached in its lifecycle | | **Created** | When the condition was detected | | **Days Open** | How long it has been outstanding | | **Modified** | When the alert was last changed | An em dash in **Battery Serial** or **Device Serial** means the alert does not relate to one. ## Status An alert carries one of six statuses: | Status | Meaning | | ---------------------------- | --------------------------------------------- | | **Opened** | Newly raised. Every alert starts here | | **Received** | Acknowledged | | **In Progress** | Being worked on | | **Waiting for Verification** | A fix has been applied and is being confirmed | | **Complete** | Resolved | | **Closed** | Finished and archived | {% hint style="info" %} **Status is not changed from this screen.** There are no controls here to acknowledge, assign or close an alert — this is a read-only view. Alerts move through these statuses elsewhere in your support process. {% endhint %} ## Controls | Control | What it does | | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | Search box | Searches the **Alert Description** text | | **Filters** | Narrows by **Alert Status** and **Alert Type**, with **Reset** to clear both | | **Refresh** | Reloads the list | | Column headings | Sort by **Alert Type**, **Alert Description**, **Status**, **Created**, **Days Open** or **Modified**. The two serial columns cannot be sorted | | Page size | 10, 25, 50 or 100 rows. Opens on 25 | The **Alert Type** filter lists the types that actually appear in your data, so it grows as new kinds of alert are raised. {% hint style="info" %} The search box looks only at the description. To find every alert for one battery, sort by **Battery Serial** is not available — filter by **Alert Type** and scan, or open the battery directly from the [Batteries inventory](/amie-advanced/using-the-platform/batteries-inventory.md). {% endhint %} ## Reading the list * **Days Open counts from when the alert was raised**, not from when the underlying problem started. A battery may have been overheating for some time before the first reading crossed the threshold. * **An empty list is good news.** It reads "No alerts to display." * **The list is not narrowed by the group selector.** Unlike most screens, changing the group in the header does not change what appears here. ## Related * [Batteries overview](/amie-advanced/using-the-platform/batteries-overview.md) — battery health across the fleet * [Battery details](/amie-advanced/using-the-platform/battery-details.md) — everything recorded about one battery * [Devices overview](/amie-advanced/using-the-platform/devices-overview.md) — device check-in activity, including long-silent devices --- # 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/using-the-platform/alerts.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.