> ## Documentation Index > Fetch the complete documentation index at: https://docs.aquaops.dev/llms.txt > Use this file to discover all available pages before exploring further. # Alerts > Track warning and critical chemical readings across your locations, outside of closure incidents. Alerts is a lightweight, always-current view of chemical readings that need attention. ## Purpose Use this module to see which pools currently have a chemical reading outside the ideal range, without digging through the full Chemical Records list. Alerts are derived automatically from chemical record submissions — nobody creates them by hand. ## Best for * a quick daily scan of "what needs attention right now" across all your locations * supervisors triaging warning/critical readings without opening every record * confirming that a corrective retest actually fixed the problem ## What generates an alert Every time a chemical record is saved, AquaOps evaluates each measured field against the pool's chemical profile and compares the result to that pool's currently **open** alerts (open = not yet acknowledged and not yet resolved): * A field that comes back **balanced** automatically resolves (`fixed`) any open alert for that field — a later good reading is treated as proof the earlier issue is over, whether or not anyone ever acknowledged it. * A field that's newly `warning_low`, `warning_high`, `critical_low`, or `critical_high` — and doesn't already have an open alert — creates a new alert. * A field that's still breaching but at a **different** status than its open alert (e.g. `warning_high` retests as `critical_high`) closes the old alert (`superseded`) and opens a new one, so there's never more than one open alert per pool/field at a time. * A field breaching at the **same** status as its already-open alert is a no-op — the ongoing issue doesn't get a duplicate row. * A field the test didn't measure, or one that came back `missing` or `closure_required`, is left alone. `closure_required` readings don't generate an alert at all — those are handled entirely through the closure incident workflow off the chemical record itself, not through this list. `warning_low` / `warning_high` map to **Warning** severity; `critical_low` / `critical_high` map to **Critical** severity. ## Alerts list Go to: ```text theme={null} Alerts ``` A banner at the top shows how many alerts are currently open. The list itself shows, for each alert: * time * location / pool * field * status (with the same status badge used on chemical records) * message (e.g. "Free chlorine is above the alert threshold") * state — acknowledged time, resolved time and reason, or an **Acknowledge** action Open alerts are sorted to the top, then everything is ordered newest-first. If the alert came from a specific chemical record, the row links straight to that record's detail page. ### Desktop vs. mobile Desktop shows the full table described above. Mobile shows the same information as tap-friendly cards. ## Acknowledging an alert Acknowledging is a manual, one-way action: it stamps `acknowledged_at` and the acknowledging user, and the alert drops out of the "open" count. There's no separate dismiss/reject action — acknowledgment is the only person-driven way to close an alert out. This is distinct from **auto-resolution**: an alert can also close itself out with a `resolved_at` timestamp and a `resolved_reason` of `fixed` (a retest came back balanced) or `superseded` (the same field breached again at a different status) — no person needs to act for that to happen. The list shows whichever happened: acknowledged time, or resolved time plus reason. ## Notifications If a user has **Chemical alerts** email notifications turned on (`Settings > Notifications`, on by default), they'll get an email whenever a new alert is created — one email per chemical record's worth of new breaches, summarizing all fields that broke on that test. Recipients are exactly the users who could already see the alert in-app: active users with `chemical_records:view` or `org:manage`, scoped to the alert's location (an `org:manage` holder sees everything). Email delivery is best-effort — if it fails or is skipped, the alert still appears in-app regardless. ## Permissions * **Viewing** the Alerts list requires `chemical_records:view`. Without it, the page shows a "you don't have permission" message instead of the list. * **Acknowledging** an alert requires `chemical_records:edit`. Users who can view but not edit chemical records see the alert's state but no Acknowledge button. * Alerts as a feature can also be turned off for your organization at the platform level. If it is, the page (and the Acknowledge action) show a "This feature isn't available for your organization" message instead. ## Typical walkthrough **1. Open Alerts** Check the open-alerts banner for a quick sense of how many issues are outstanding. **2. Review an alert** Read the message and, if it's linked to a chemical record, open the record for full context. **3. Take corrective action** Address the underlying chemistry issue, then re-test the pool. **4. Let the retest confirm it** If the retest comes back balanced, the alert resolves itself as "fixed" — no action needed here. **5. Acknowledge if appropriate** If the reading is being tracked another way (e.g. a closure incident) or you simply want to mark it as seen, use Acknowledge. ## Best practices * treat Alerts as a triage view, not a replacement for reviewing full chemical records * don't rely on acknowledging as a substitute for actually re-testing — only a balanced retest closes the underlying issue * keep your chemical alert email notifications on if you're responsible for a location, so you don't have to keep the list open to notice new breaches * remember `closure_required` readings won't show up here — check the compliance/closure workflow for those * review pool chemical profiles periodically, since alert thresholds come directly from them ## Suggested screenshots * desktop alerts list with the open-alerts banner * mobile alert cards * an alert row with the Acknowledge button visible * an alert row showing an auto-resolved ("fixed" or "superseded") state * the "you don't have permission" empty state This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.