---
sourceDocument: Australia IT Operations Management
sourceDocumentLink: https://www.servicenow.com/docs/r/australia/it-operations-management

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia IT Operations Management

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

# Checks and policies

# Checks and policies {#ariaid-title1}

Release version: Australia  
Updated March 12, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 6 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Checks and policies

Checks in the Agent Client Collector (ACC) framework combine commands with configurations to gather monitoring data from devices.
Delivered with the base system, these checks execute scripts on monitored devices to collect data about operating systems and applications, such as CPU usage on Linux systems.
Checks are defined ascheck definitionsand becomecheck instanceswhen associated with policies.
Check instances can be customized per policy without affecting the original definitions or other instances.
Show full answer Show less  

## Key Features

* **Check Types:** Event checks convert results into Event Management events; Metric checks transform results into metrics.
* **CPU Protection Mode:** When a device's CPU usage is too high, checks may be disabled to protect performance. Thresholds and behaviors are configurable via the `acc.yml` file. Disabled checks can be viewed and re-enabled in the Agent Client Collector interface.
* **Stale Checks:** Checks no longer linked to policies are marked as stale and can be re-enabled or removed.
* **Exit Status and Severity:** Checks use exit status codes to indicate severity levels (0=OK, 1=WARNING, 2=CRITICAL), with support for custom severities like MAJOR and MINOR through scripting.
* **Privilege Requirements:** ServiceNow users running checks require specific OS privileges:
  * **Linux:** Configure sudo permissions with environment preservation and no tty/password requirements.
  * **macOS:** Ensure the agent user group has privileges to query TCP connections.
  * **Windows:** Add the ServiceNow user to groups with necessary command execution rights.
* **Handling Missed Check Executions:** If a device or agent is offline during a scheduled check, the check runs upon reconnect with a delay (up to 60 minutes). The scheduling adapts based on whether the check ran previously, maintaining original intervals.
* **Policies:** Policies link configuration items (CIs) with check definitions. Credential aliases allow a single policy to support multiple credentials, enabling efficient monitoring across diverse environments. Alerts from event-type checks in policies are automatically closed if monitoring stops due to policy or check deactivation or deletion.

## Practical Benefits for ServiceNow Customers

Understanding checks and policies allows customers to effectively monitor their environment by customizing check executions, managing system resource constraints through CPU protection, and ensuring proper privileges for data collection. Policies simplify managing monitoring scopes and credentials, while automated alert closure helps maintain accurate incident states. This knowledge empowers customers to optimize monitoring configurations, troubleshoot issues related to check execution, and maintain system performance and security compliance.  
A check is a combination of a command and its configuration. The check is executed on the Agent Client Collector's devices to gather data from those devices.

## Checks {#checks-policies__section_j2b_5hb_rwb}

Checks are provided with the base system, and their commands execute scripts which provide monitoring data for your operating systems and applications. A check's default name indicates what is being monitored and measured, the
entity, and the monitoring data. For example, a check named os.linux.check-system-cpu checks the CPU data on a Linux system. The identified command in the check runs on the monitored device, providing an output and status. Each individual check is referred to as a check definition. After being
associated with policies, check definitions are then referred to as check instances.

You can customize check instances to meet your needs. For example, customize the running interval or the parameters specific to the policy, such as the login credentials to access a MySQL database. Customization of a check
instance takes effect only on the check instance associated with the policy. It does not affect the original check definition or check instances already created in other policies.

The following check types are provided with the Event Management base system:

* Event: The check's result is transformed into an Event Management event.
* Metric: The values from the check result are transformed to metrics.

{#checks-policies__ul_omn_1rr_rjb}

For details on the Agent Client Collector Framework default checks, see [Agent Client Collector Framework default checks](https://www.servicenow.com/docs/EJLjqXNVqQuoSzdKprU4hw "Agent Client Collector Framework provides default checks with the base system.").

For details on the Agent Client Collector Monitoring default checks and policies, see [Agent Client Collector Monitoring default checks and policies](https://www.servicenow.com/docs/Rfj4K4PI62iVo67NDlzAmw "Agent Client Collector Monitoring provides various default checks and policies.").

For details on the Agent Client Collector for Visibility Content default checks and policies, see [Agent Client Collector for Visibility Content default checks and policies](https://www.servicenow.com/docs/oTbnJzTn7ni4d~Q5ne7XtA "Agent Client Collector for Visibility Content (ACC-VC) provides various checks and policies as well as a business rule.").

If checks are not running on the agent's devices, your agent may be in CPU protection mode. CPU protection mode is activated when a device's CPU consumption is too high. To view a list of all disabled checks related to the
agent, navigate to the agent record on the Agent Client Collectors page (AllAgent Client CollectorAgents). Select an agent, then select the Disabled Checks tab at the bottom of the page.

In the acc.yml configuration file, you can modify the CPU protection mode thresholds which determine when a check is disabled. To re-enable a check, select the check and select
Re-enable disabled check in the Actions on selected rows... drop-down. For details on the CPU protection mode thresholds, see [Agent Client Collector CPU protection thresholds](https://www.servicenow.com/docs/ffE7CkmdySTk8JBW6S8BXA "When an agent meets the configured thresholds specified in the agent's acc.yml file, it enters CPU protection mode, either for an individual check or for all checks. Agents in CPU protection mode appear in the agent logs with the syntax Agent Protection."). For details on manually turning off data collection, see [Pause Agent Client Collector data collection](https://www.servicenow.com/docs/W9Uh717PUUnPevPMCkDRfQ "If CPU consumption on your server is getting too high, you can manually turn off the Agent Client Collector data collection. This pauses all checks performed by the agent, except for the agent's keep alive messages.").

Configure the cpu_protection_behavior property to determine whether all checks enter CPU protection mode, or only the check with the highest CPU usage that crosses the configured cpu_percentage_limit value
within the monitoring interval. For details, see [Agent Client Collector CPU protection thresholds](https://www.servicenow.com/docs/ffE7CkmdySTk8JBW6S8BXA "When an agent meets the configured thresholds specified in the agent's acc.yml file, it enters CPU protection mode, either for an individual check or for all checks. Agents in CPU protection mode appear in the agent logs with the syntax Agent Protection.").

A check is marked as Stale if it is no longer associated with a policy. To remove a stale check, renable it by selecting the box next to the check and selecting
Re-enable disabled checks from the Actions on selected rows... cell.  
In the base system, the event's exit status indicates its severity, as follows:

* 0 = OK
* 1 = WARNING
* 2 = CRITICAL
{#checks-policies__ul_dfd_pwr_1pb}  
You can add additional severities (such as MAJOR and MINOR) by running a customized script. The following exit statues indicate these severities:

* 13 = MAJOR
* 14 = MINOR
{#checks-policies__ul_r55_1mb_35b}

## Privileges for running check commands {#checks-policies__section_qqz_4d1_vdc}

If the servicenow base system user does not have privileges to run specific check commands, do the following for the relevant operating systems:

* In a Linux system: Enable the servicenow user to run the command with `sudo` permissions. Ensure that the following sudo configuration requirements are met:
  * Disable tty and password requirements
  * Preserve all environment variables
  * Support dynamic PATH for executing commands

  {#checks-policies__ul_yzj_f2g_n4b}  
  Example configuration in the /etc/sudoers file:

      Cmnd_Alias ACC_F = /usr/sbin/dmidecode -s baseboard-serial-number, /usr/sbin/dmidecode -s chassis-serial-number, /usr/sbin/dmidecode -s system-serial-number, /usr/sbin/dmidecode -s system-uuid, /usr/sbin/ss -tanp 
      servicenow ALL=(root) SETENV: /var/cache/servicenow/agent-client-collector/osquery/bin/osqueryi *, ACC_F
      Defaults:servicenow !requiretty
      Defaults exempt_group += servicenow

  Note:  
  Command paths may vary. Consult the sudoers manual for special considerations.
  * The `SETENV:` string enables the servicenow user to preserve environment variables.
  * The `!requiretty` string disables tty.
  * Adding the servicenow user to the `exempt_group` bypasses password requirements and enables dynamic PATH for executing sudo commands.

  {#checks-policies__ul_br4_4fg_n4b}

  Ensure that you configure the must_sudo check parameter with a value of true in the check command parameters section of the check definition.
* In a macOS system: Ensure that the user running the agent service belongs to a user group with privileges to query all tcp connections on the host.
* In a Windows system: Using Windows User Management, add the servicenow user to the groups with the relevant privileges, enabling the user to execute the required commands.
{#checks-policies__ul_ynm_ysy_4mb}

## Executing checks that missed their execution time {#checks-policies__section_nt2_lps_r3c}

A check doesn't execute if the laptop or agent is down during its scheduled execution time. When this happens, the system behavior depends on whether the check has executed previously.

* Check that never executed: The check runs at the agent reconnect time + X (where X = 0-60 minutes), and this is the permanent run time of the check.For example: Policy X was synced to an agent. Check A in the policy
  never ran previously and was scheduled to run at 2am. However, the laptop was asleep at that time. The laptop wakes up at 9:09am. After the agent is restored, it notices that check A never ran. Check A is scheduled to
  run between 9:09am-10:09am and ends up running at 9:54am. The check A interval is every 24 hours, so check A now is scheduled to run daily at 9:54am.

* Check that missed an existing execution time: The previously run check runs at the agent reconnect time + X (where X = 0-60 minutes), but in the future, the check reverts to its originally scheduled run time.For
  example: Check A runs once a day and is scheduled to run daily at 9:54am. The laptop was asleep or the agent was not connected from 9am until 1pm. At 1:17pm, the laptop is awake and the agent starts and connects. The
  agent noticed that check A did not run at 9:54am and schedules it to run between 1:17pm-2:17pm. The check ends up running at 1:37pm. However, the next time check A runs is at 9:54am, its originally scheduled
  time.

  This scenario takes effect only for checks running at an interval of every 60 minutes or more frequently. Checks that run less often than every 60 minutes run at their previous interval time.
{#checks-policies__ul_uyr_gqs_r3c}

## Policies {#checks-policies__section_ftj_c3b_rwb}

A policy is a combination of the CIs being monitored by the Agent Client Collector and the check definitions that run on those CIs.

To enable a single policy to support multiple credentials, assign a credential alias to the policy. For example, if you have MySQL servers for both Linux and Windows with different credentials, you must create separate policies for each credential type. However, if you use a credential alias, you can assign a single policy to the alias. The agent then matches the
relevant credential to the application being monitored. For details on credential aliases, see [Create a Connection and Credential alias](https://www.servicenow.com/docs/access?context=connection-alias&version=australia&pubname=australia-platform-security&ft:locale=en-US).  
Alerts generated by policies with an event-type check are automatically closed when the CI monitoring stops due to any of the following:

* De-activating the policy
* De-activating the check that caused the alert
* Deleting the check from the policy
* Deleting the policy
* Modifying the policy filter that determines the monitored CIs
{#checks-policies__ul_sc2_zds_j4b}

*[\>]: and then