The Policy Engine lets you express rules like “Fail2Ban must be enabled on every production server” or “Disk usage must stay under 85%” and have HostAtlas continuously check them across your fleet. When a server drifts, a Policy Violation is opened; when the server comes back into line, the violation resolves itself.

You’ll find it in the sidebar under Security → Policies.

What you see

The index page lists every policy your tenant has defined, with:

• Name, category (Security, Compliance, Reliability, Cost…), severity, status (active / paused).
• Number of servers currently in violation.
• Last evaluation time.

A KPI header shows the total number of open violations across all policies.

A policy detail page shows:

• The rule the policy uses, plus its parameters (thresholds, expected values).
• The target filter — which servers this policy applies to (tags, hostname pattern, or “all”).
• The latest per-server evaluation results: OK, In Violation, or Not Applicable.
• Every open violation for this policy, with the affected server and first/last seen timestamps.

What you can do

• Create a policy. You pick a rule from the built-in catalogue (grouped by category), set severity (info → critical), fill in the rule parameters, and scope the policy to a subset of servers via tags or a hostname pattern. Leaving the target filter empty means “all servers”.
• Re-evaluate now — force an immediate run against the current fleet state.
• Delete a policy — this also closes its open violations.
• Acknowledge a violation with an optional note. The violation stays open (visible in the fleet count) but is marked as “someone’s looking at it”.

Note

Creating a policy triggers an immediate first evaluation so you see results without waiting for the next scheduled run.

How it works

The rule catalogue is built into HostAtlas — each rule knows what data to look at (agent metrics, discovered packages, firewall snapshot, SSH Gatekeeper state, backup status, and so on) and how to decide OK vs. In Violation.

For every active policy, the engine walks the servers that match the target filter and runs the rule with your parameters. The outcome per server is stored so the policy detail page can show it, and a violation is opened for any server that fails.

• Violations stay open as long as the condition is failing.
• When the next evaluation shows the server is back OK, the violation is auto-resolved with the timestamp.
• Acknowledging a violation records who and when — it does not resolve it; only the server coming back into compliance does.

Evaluation runs on a schedule and after material state changes (a new agent snapshot, a new scan result, etc.). You can always force a run from the policy page.

Categories & rules (examples)

• Security — Fail2Ban enabled; SSH Gatekeeper enforced; no root SSH login; CVE severity ceiling.
• Reliability — Backup ran in the last N hours; disk usage below threshold; agent version at or above baseline.
• Compliance — Audit findings resolved within N days; session recording enabled; log forwarding configured.
• Cost — Server underutilised for N days; oversized instance.

The concrete rule list you see in Create Policy is the source of truth — HostAtlas ships rules as it adds signals to the platform.

Related

• Policy Violations — the cross-policy feed of open violations.
• Vulnerabilities — the CVE data many security policies read from.
• SSH Gatekeeper — one of the standard signals policies can enforce.