Skip to main content
A policy is a rule you define once — “disk usage under 80%,” “agent version up to date” — that AssetGullak checks on a schedule, automatically, across whichever devices or assets you point it at. When something breaks the rule, that’s a violation, and it stays visible until the underlying problem is actually fixed.

​
Policy types

Ten types, covering three different things a policy can watch: Device health & configuration Resource usage Software Assets (these watch physical assets, not devices)
Resource usage policies (CPU/RAM/Disk) can optionally require the breach to be sustained over a time window you choose, rather than flagging on a single instantaneous reading. This is the difference between “disk hit 85% for one reading” and “disk has been over 85% for the last 30 minutes” — the second is a real problem, the first might just be a backup job running. Use a sustained window if you want to avoid noise from brief spikes.

​
Who a policy applies to

Every policy has a target — company-wide, a specific location, a department, a single device, or a tag. A policy only evaluates devices (or assets) inside its target; nothing outside it is touched.

​
How evaluation actually works

Policies are checked automatically, roughly every 10 minutes — you don’t trigger this yourself. Each enabled policy runs independently, so a slow evaluation on one policy never delays another.
Just fixed something and don’t want to wait for the next automatic check? There’s a manual re-check action on the policy’s detail page that evaluates it immediately.
For every device or asset in a policy’s target, evaluation lands on one of three outcomes:
  • Compliant — evaluated, and it meets the rule.
  • Violating — evaluated, and it breaks the rule. This opens (or keeps open) a violation.
  • Not applicable — the policy couldn’t be evaluated for this subject right now (most commonly: a resource-usage policy needs data from the last N minutes, and none has come in yet). Not applicable subjects are excluded from both the compliant and violating counts — they’re neither.

​
Violations open and resolve automatically

You never manually close a violation because the underlying problem got fixed — the next evaluation cycle does it for you. A violation resolves when either:
  • The subject is re-evaluated and is now genuinely compliant, or
  • It’s no longer targeted by the policy at all (the device was removed, or the policy’s targets changed)
One deliberate exception: if a device goes from violating to not applicable (for example, it briefly stops reporting metrics), the violation is left open, not auto-resolved. This is intentional — a gap in data isn’t confirmation that the problem is fixed, so AssetGullak doesn’t clear the flag just because it temporarily can’t check. The violation only resolves once a real evaluation confirms compliance, or the device is removed from the policy’s scope.

​
Previewing before you commit

When creating or editing a policy, you can preview its effect before saving — it runs a live evaluation against your real fleet and shows you how many devices would currently comply or violate (“18 of 200 would violate”), without writing anything. Useful for catching an overly strict threshold before it floods your Alerts with new violations the moment you enable it.

​
Where violations show up

  • On the policy itself — its detail page shows live compliant/violating counts and the list of currently-violating devices or assets.
  • On the device timeline — only for device-subject policies (resource usage, software, OS/agent version, uptime). Asset-subject violations (warranty, asset age) don’t have a device to attach to, so they surface through Alerts and reports instead.
  • In Alerts — see Alerts vs. Policy Violations for exactly how the two relate; they’re not quite the same thing.

​
How this relates to your dashboard’s compliance score

The number on your dashboard is fleet-wide: the share of your devices with zero open violations, across every policy. A device counts against that score if it’s violating any enabled policy, even just one — the per-policy compliant/violating counts you see on each policy’s own page are narrower, scoped to that one policy’s targets. A device can be compliant on nine policies and violating on a tenth; it still counts as non-compliant on your dashboard.

​
Next

Alerts vs. Policy Violations clears up a common point of confusion — these look similar but come from different places.