Monitoring & alerts
The scheduler evaluates alert rules every interval, opens and resolves alert events, and delivers them to your sinks. The audit log exports to a SIEM.
What Portrait collects
Agents ship inventory (hardware, network, software across every provider, OS and pending-reboot state), a set of system metrics rolled up hourly with retention, security posture (Defender, firewall, BitLocker status, Secure Boot, TPM), running processes and services, and local accounts. Where Windows does not expose a signal - a load average, a third-party package severity - Portrait reports its absence rather than inventing a number.
Alert rules and events
An alert rule defines a condition over that data - a host gone silent, a security posture regression, a stalled or repeatedly failing activity, a pending reboot outstanding too long, an unknown identity knocking, a disk under pressure. When the condition holds, the scheduler opens an alert event in the firing state; when it clears, the same event resolves. The nav badge and a landing banner surface firing alerts in the UI, and each rule’s time-bounds (how long before an activity failure escalates, how long a stall is tolerated) are configurable per rule.
Every rule is evaluated in its own savepoint, so one bad rule cannot abort the whole evaluation pass. Rule evaluation failures are themselves recorded as system events and surfaced in-product, not just in the journal.
Notification sinks
A firing event is delivered to the configured notification sinks:
- SMTP - email to an address or list.
- Webhook - an HTTP
POSTwith an HMAC signature over the body, so the receiver can verify the payload came from your Portrait instance.
Sinks are configured with notification_sink.manage. A sink can be disabled
without deleting it.
Suppressing an alert
Some alerts will never clear on their own by design - a host with BitLocker deliberately off, a disk-pressure control case you are choosing to live with. Suppressing an alert requires an expiry and a written justification, and the suppression can be scoped to a specific activity type rather than silencing everything about the host. A suppressed alert still exists and is still visible; it just does not page you.
Audit-log export
Every authorization-relevant action - a login, a role change, an approval, a script run, a profile edit - lands in the audit log. It is queryable through the API and exports continuously to a SIEM in CEF or NDJSON. The export contract is covered by tests, so a field rename cannot silently break your downstream parsing.