Monitors

Monitors are automated checks that Oneleet runs every hour against your assets, such as user accounts, cloud resources, devices, and vendors, to show you which of them need fixing. Each asset a monitor checks gets its own result, and those results determine the monitor’s status. If the monitor backs a compliance control, its status contributes to that control’s status. For example, the AWS IAM user accounts with console access have multi-factor authentication enabled monitor checks each IAM user that has console access and alerts when one or more of them don’t have MFA enabled.

Monitors are part of every Oneleet compliance package. Members, Auditors, and Admins can view monitors and their asset results, and Members and Admins can rerun a monitor. Only Admins can snooze, disable, or change the settings of a monitor, or ignore or snooze its assets. Members see those actions in the app, but only an Admin can complete them. If your workspace uses organization roles, your access depends on the permissions your role grants (see Role-based access control).

Find monitors under Monitors in the sidebar. Relevant monitors also appear on integration and device pages.

How monitors are added

You don’t create monitors. Oneleet adds the monitors relevant to your controls once it has the data to run them, for example after you connect an identity provider, a cloud environment, or a source-code provider. This happens in an hourly background job, so a monitor for a newly added control or integration appears within about an hour. If the integration has no assets the monitor applies to, the monitor is still added and shows No applicable assets. Some controls have no monitor at all.

On the Monitors page, monitors whose assets come from Oneleet itself rather than from a connected integration are grouped under Oneleet. These include monitors on your compliance program data, domains, pentest engagements, devices running the Oneleet agent, vendors, and findings from Oneleet’s own security scans.

New monitors start snoozed

When we introduce a new check, the monitor for it starts Snoozed so that your workspace isn’t immediately affected by it. The snooze ends seven days after we introduced the check. If the check was introduced more than a week before the monitor is added to your workspace, the monitor starts active and is checked on the next hourly run.

If your workspace is in a SOC 2 Type 2 observation period, new monitors are instead snoozed until 28 days after the latest observation period ends, however old the check is. This keeps a new check from creating exceptions partway through the period.

A snoozed new monitor has no asset results until its snooze ends. To see its results sooner, click Unsnooze on the monitor’s page, which runs it right away.

Monitor statuses

Every monitor has one status, based on its latest run. The status also sets the monitor’s effect on the controls it backs.

Status	Meaning	Effect on controls
Breaching SLA	At least one asset is past its SLA deadline.	Failing check
Alerting	At least one asset fails the check, and none is past its SLA deadline.	Failing check
Passing	Every asset passes.	Passing check
No applicable assets	Oneleet has nothing for this monitor to evaluate right now, including when every asset is ignored or snoozed. This isn’t a failure.	Inactive, counts neither way
Pending	The monitor hasn’t run yet, or its snooze has ended and it hasn’t run since.	Inactive, counts neither way
Snoozed	The monitor is paused until a date.	Inactive, counts neither way
Disabled	The monitor is turned off until someone re-enables it.	Inactive, counts neither way

Each asset has its own result: Breaching SLA, Alerting, Passing, Ignored, or Snoozed. Ignored and snoozed assets don’t count toward the monitor’s status.

What this means for your audit: A passing monitor means the check passes in Oneleet, not that an auditor has reviewed or accepted anything. An alerting monitor whose failing assets are all still within their SLA deadlines isn’t an audit problem, even though its control’s check reads as failing, because fixing issues within the SLA is the expected process. A monitor that breaches its SLA during a SOC 2 Type 2 observation period can become an exception on your audit report.

SLA deadlines

An SLA deadline sets how long you have to fix a failing asset before its monitor moves to Breaching SLA. Each asset’s deadline is the time it started alerting plus the hours your workspace sets for that asset’s SLA type, such as security alerts, access reviews, or a vulnerability severity.

Deadlines exist only when SLAs are enabled. To turn them on, open SLAs in the sidebar and switch the setting on the Service level agreements page to Enabled. Set your SLA hours to match the remediation timelines in your own policies, such as your vulnerability management policy, because auditors test against the policy.

Each failing asset row shows when the asset started alerting and when it breaches or breached its SLA. While the monitor is Alerting, its page also shows a warning that it has alerting assets that will breach their SLA, however far away the nearest deadline is.

Fix a failing monitor

1. On the Monitors page, click the Breaching SLA or Alerting filter. The list is sorted by Most urgent by default, which puts the monitors with the nearest or longest-missed SLA deadlines first.

2. Click a monitor to open its page, and read How to remediate.

3. Click Review issues to jump to the failing assets. This shows only Alerting assets, so on a Breaching SLA monitor, click the Breaching SLA filter in the Assets section to see the assets that are past their deadline.

4. On each asset row, hover over or click Result (1) or Results (N) to read why the asset failed. Click View to open the asset in the system it comes from.

5. After you fix the issue, click Rerun monitor in the Details section. The page updates on its own until the run finishes.

If you don’t rerun it, the monitor picks up your fix on its next hourly run. Oneleet sets the minute of the hour when your workspace’s monitors run.

Monitors that report findings from Oneleet’s code security, dependency scanning, application security, and attack surface scans can’t be rerun by hand, because they update from those scans.

Troubleshoot a failed run

When a run fails because of missing permissions or an internal error, the monitor’s page shows one of these callouts:

• Integration is missing permissions to run this monitor: click Check connection status to review the integration’s connection.
• Internal error, followed by when the last run happened: the run couldn’t be completed. Click Check connection status. If that doesn’t reveal anything and the problem persists, contact Oneleet support and cite the monitor URL shown in the callout, which has a copy button.

Problems with the integration itself show at the top of the monitor’s page as Integration service disrupted, Integration service degraded, or Permissions update required. Click View details to see the integration’s status.

A run that times out or is canceled doesn’t show a callout. It appears only in the monitor’s history, labeled Timed Out or Canceled (see Review a monitor’s history).

Exclude an asset or monitor

When a failing asset isn’t something you need to fix, take that one asset out of the monitor’s results instead of pausing the whole monitor.

• Ignore an asset to exclude it from the monitor’s results until you re-enable it. It stays listed under the Ignored filter in the Assets section.
• Snooze an asset to pause its alerts until a date you choose, after which they resume automatically.
• Snooze a monitor to pause the whole monitor until a date.
• Disable a monitor to turn it off until someone re-enables it, with a reminder to review that decision.

Snoozing or disabling a monitor is recorded in the audit log and needs a real justification, which auditors can ask about. Neither is a way to opt out of a requirement.

To snooze or disable several monitors at once, select them on the Monitors page and use the action panel. Each monitor is updated separately, so some can succeed while others fail, and the message that appears says how many failed.

Snooze dates, for assets and monitors alike, end at 9:00 AM in your local time, so Tomorrow ends the snooze the next morning rather than 24 hours later.

Ignore or snooze an asset

1. In the monitor’s Assets section, open the asset row’s action menu and choose Ignore, or choose Snooze and a date. To act on several assets at once, select their rows and use the action panel instead.

2. Enter your reason.

3. To apply the action to every monitor that checks the asset, turn on Ignore for all monitors or Snooze for all monitors.

4. Click Ignore asset or Snooze asset (Ignore assets or Snooze assets for several).

Snooze for all monitors is offered only when you snooze a single asset, so snoozing several assets at once applies to the current monitor only. Ignoring several assets still offers Ignore for all monitors. That switch covers only the monitors that check the asset when you ignore it, so a monitor added later still evaluates the asset.

Both actions rerun the monitor, and it shows as running until the run finishes. You can keep ignoring or snoozing other assets while it runs, and ignored rows switch to Ignored right away. Ignoring an asset removes any snooze on it for that monitor, and snoozing an ignored asset un-ignores it.

Document why you’re ignoring an asset, such as it being out of scope, and make the reason match the scope in your workspace’s system description. To see an asset’s snooze reason, hover over its Snoozed until date. An ignore reason appears as the asset’s result reason once the rerun finishes, and until then the row shows its previous failure reasons.

An expired asset snooze clears on the monitor’s next run, so a row can show a past Snoozed until date for up to an hour.

To bring back a snoozed asset, choose Unsnooze from its action menu. For an ignored asset, choose Re-enable now from the same menu, or choose Re-enable in… to snooze the asset until a date you pick. Once that snooze ends, the monitor checks the asset again.

You don’t need to ignore a retired device, because removed, archived, and blocklisted devices drop out of device monitors on their own at the next asset sync.

Snooze a monitor

1. On the monitor’s page, open the ⋮ menu and choose Snooze monitor.

2. Pick a date from the options, which run from Tomorrow to 6 months from now, or choose Choose date… to pick any future day up to about two years ahead.

3. Enter a Reason for snoozing and click Snooze monitor.

Snoozing takes effect right away. The monitor’s control checks become inactive, so the controls stop failing before any run, and scheduled runs stop checking its assets. Every asset’s result becomes Snoozed and its SLA clock resets, so after the snooze ends, each asset’s deadline counts from the next run rather than picking up where it left off.

The monitor’s page shows the snooze date, who snoozed it, and the reason. When the snooze ends, the monitor shows Pending until its next hourly run completes. To end the snooze early, click Unsnooze, which runs the monitor right away.

Disable a monitor

1. On the monitor’s page, open the ⋮ menu and choose Disable monitor.

2. Enter a Reason for disabling.

3. Under Review reminder, choose when to be reminded, from Tomorrow to Next year. There’s no default, so you have to pick one.

4. Click Disable monitor.

A disabled monitor stops checking its assets and alerting you, and its control checks become inactive. Its asset results are deleted, so the Assets section is empty, and when you re-enable the monitor, every asset’s SLA clock starts fresh.

On the review date, subscribed members get a review reminder, and the monitor’s page shows that it’s due for re-review. The monitor stays disabled until someone acts. Click Re-monitor now to re-enable it, or Keep disabled to choose a new review date.

To re-enable a disabled monitor at any time, open the ⋮ menu and choose Re-enable now, or Re-enable in… to snooze it until a date, after which it runs again.

Change a monitor’s settings

A few monitors have a Settings section on their page. Change the value and click Save.

Setting	What it controls	Allowed values	Default
Dormant account threshold	How many days an account can go without an authentication event before it counts as dormant	0 to 90 days	90 days for GCP service accounts and keys, 45 days for Google Workspace users
Rotation threshold	How many days a KMS key, API key, or access key can exist before it should be rotated	1 to 365 days	90 days
Flow Log Retention Period	How many days Azure network watcher flow logs should be kept	90 days or more	90 days
Minimum length	The shortest Minimum character length a Bitwarden organization’s master password policy can set (see Bitwarden master password settings)	8 to 128 characters	12 characters
Minimum complexity	The lowest Minimum complexity score a Bitwarden organization’s master password policy can require	Off, Good (3), or Strong (4)	Good (3)
Maximum allowed timeout	The loosest Maximum allowed timeout a Bitwarden organization’s session timeout policy can set (see Bitwarden session timeout settings)	Immediately, Custom, or On system lock	On system lock
Maximum custom timeout	The longest Custom timeout the session timeout policy can set	1 to 10,080 minutes, or empty for no maximum	No maximum
Required timeout action	Which Session timeout action the session timeout policy must set	Lock or Log out, or Log out	Lock or Log out

Review a monitor’s history

On a monitor’s page, click View history in the sidebar, under the heading that shows the monitor’s asset count (for example, “12 assets”). The history shows:

• History: each time the monitor’s status changed. Expand an entry to see the reason or the assets involved.
• Recent runs: the 24 most recent runs, which at one run per hour covers about the last day. A snoozed or disabled monitor still records a Succeeded run each hour, even though those runs don’t check its assets.

Monitor actions also appear on the Audit log page, which only Admins can open. It records reruns, snoozes, unsnoozes, enabling and disabling, settings changes, and ignored or snoozed assets, but not the reason given. A monitor’s snooze or disable reason is on the monitor’s page, and an asset’s reasons are on its row (see Ignore or snooze an asset).

Monitor notifications

Workspace members subscribed by email get these notifications about monitors:

• Monitor alerts: sent when a monitor starts alerting after passing or another non-failing status. A monitor that goes from Breaching SLA back to Alerting doesn’t send one.
• SLA breach alerts: sent every time a monitor moves to Breaching SLA.
• Monitor at risk warnings: sent when a run finds the monitor within two days of its earliest asset deadline.
• Monitor review reminders: sent when a disabled monitor reaches its review date.

You get one at-risk warning per stretch of Alerting, and none while the monitor is Breaching SLA. If you fix the asset it warned about and other assets keep the monitor alerting, a different asset nearing its deadline later gets no warning, and you’ll only hear about it when it breaches.

For how these notifications are combined and delivered, see the notification catalog. Monitor status updates also appear in the Monitors section of the digest.

Less common situations

• Turning off employee checklists: If you turn off Employee checklists on the Settings page, the checklist monitors are disabled and show “This monitor has been disabled for your organization by Oneleet.” in place of a reason.
• Removing a framework: If you remove a framework, monitors used only by the controls it removes are archived and disappear from the Monitors page. Monitors that remaining controls still use keep running.
• A single device’s monitors: On a device’s page, the Monitors tab shows each monitor’s result for that device alone. A monitor reads Ignored there if you ignored that device on it.