> ## Documentation Index
> Fetch the complete documentation index at: https://docs.assetgullak.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Alerts vs. Policy Violations

> They're not two different things — here's how they actually relate.

Short version: **an alert *is* a policy violation.** There's no separate system behind Alerts — it's the same underlying data as [Policies & Compliance](/core-concepts/policies), shown through a different lens.

## Two views of the same thing

* **A policy's own page** shows violations scoped to *that one policy* — useful when you're asking "is this specific rule being followed?"
* **The Alerts page** shows violations from **every policy at once**, prioritized by severity — useful when you're asking "what needs my attention right now, across everything?"

Same rows, different framing. Nothing you do on one is invisible to the other.

## The one real difference: acknowledging

Alerts add exactly one thing violations don't otherwise have: you can **acknowledge** one, meaning "I've seen this, I'm on it."

This matters because acknowledging and resolving are not the same action, and mixing them up is the most likely confusion here:

|                 | What it means                | Who does it                | Does it fix anything?        |
| --------------- | ---------------------------- | -------------------------- | ---------------------------- |
| **Acknowledge** | "I've seen this"             | A person, manually         | No                           |
| **Resolve**     | The problem is actually gone | AssetGullak, automatically | Yes — this is the actual fix |

Acknowledging is a note to your team, not a fix. It's fully reversible (unacknowledge if you marked something by mistake), and it doesn't change whether the underlying device or asset is actually compliant. **Only an automatic policy re-check can resolve an alert** — the same mechanism described in [Policies & Compliance](/core-concepts/policies#violations-open-and-resolve-automatically). There's no manual "mark as resolved" button, on purpose: resolving should mean the problem is verifiably gone, not just that someone clicked a button.

So an alert moves through up to three states:

1. **Open** — violating, nobody's acknowledged it yet
2. **Acknowledged** — violating, but someone's flagged they're handling it
3. **Resolved** — the next policy check confirmed it's actually fixed

<Tip>
  If you acknowledge something and then the underlying policy check finds it's still violating on the next cycle, it stays acknowledged — it doesn't reset to Open. Acknowledging survives until the problem is genuinely fixed.
</Tip>

## Severity badges

The counters at the top of the Alerts page (Critical / Warning / Info) always reflect **every currently active alert**, regardless of whatever filters you've applied to the list below. If you've filtered down to one device and the badges still show fleet-wide numbers, that's expected — the badges and the list answer different questions.

Severity itself comes from the **policy**, not the individual alert — every violation of a given policy carries that policy's severity.

## Devices and assets both show up here

Most alerts are about devices, but a few policy types — Warranty Expiry, Asset Age — watch physical assets instead. Those alerts look the same, just without a device status badge, since there's no device attached.

## Next

Head back to [Policies & Compliance](/core-concepts/policies) for how the underlying evaluation actually works, or continue to [Features](/features/devices) to see these in context on real device and asset pages.