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

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia IT Operations Management

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

# Collect data from your system devices

# Collect data from your system devices {#ariaid-title1}

* Release version: Australia
* 
* Updated March 12, 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 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 Collect Data from Your System Devices

This guide outlines how to collect data from system devices using the Agent Client Collector.
It details the types of data that can be gathered, the policies that govern data collection, and the scheduling models for running checks on Configuration Items (CIs).
Show full answer Show less  

## Key Features

* **Data Collection:** Collect various types of data, including monitoring data, visibility data, log data, and user metrics by executing checks on your server or database.
* **Policies:** Define which CIs are monitored and specify the checks to be executed, including command type, timeout, and necessary plugins.
* **Scheduling Models:** Choose between interval-based or cron-based scheduling for running checks to ensure timely data collection.
* **Mapping and Updates:** Policies automatically map monitored CIs and update every seven days or every 15 minutes based on changes in the CMDB.

## Key Outcomes

By implementing these data collection strategies, ServiceNow customers can effectively monitor their system devices, ensuring data integrity and timely insights. Customers can expect automated updates and the flexibility to adjust monitoring parameters as needed for optimal performance.  
Run a check command on your server or database to gather data from those devices. Depending on the check that is invoked, collected data may be monitoring data, visibility data, log data, or user metrics.

## Policies {#checks-policies-working-with__section_axd_fjs_dgc}

A policy consists of the
Configuration Items (CIs) monitored by the Agent Client Collector, and the checks that run on those CIs. Policies define which checks to run, as well as when and on which CIs to run them.

## Checks {#checks-policies-working-with__section_snq_rqf_zfc}

A policy runs a set of checks. Each check is defined with the following attributes:

* Command to run
* Check type
* Command timeout
* Plugins to be used (tar.gz files that are securely and automatically downloaded to the agent)
{#checks-policies-working-with__ul_yqg_5qf_zfc}

## Determining when checks run {#checks-policies-working-with__section_mcd_vsf_zfc}

Policy checks run based on one of the following scheduling models:

* Interval-based scheduling: The minimum number of seconds between each check run. For example:
  * An interval value is at least once per hour (at least once every 3,600 seconds).
  * The agent was down during the scheduled interval when the check was to run.

  {#checks-policies-working-with__ul_ewd_xvl_bgc}When the agent is back up, it runs the check within one hour.

  If a check interval is less than one hour, the check is executed based on the indicated amount of time since the
  check's most recent run. For example, for a check scheduled to run once
  every eight hours:
  * The check runs at 00:00 (midnight)
  * The check runs again at 08:00 (8 AM)

  {#checks-policies-working-with__ul_g3s_byf_zfc}

  However, if the agent is down at 8:00 and is back up at 09:03, the check runs within an hour; that is, between 09:03 and 10:03. If the check runs at 09:57, the next run is at 17:57 (5:57 PM). In these cases, the check picks
  the running time at random to ensure running of once every eight hours.

  A check
  completes its run when the results are sent to the MID Server (in a MID deployment) or ITOM Cloud Services (ICS) Pod (in a MID-less deployment).
* Cron-based scheduling: Runs at fixed times or intervals (for example, every day at 6:00 PM or every two hours).
{#checks-policies-working-with__ul_trr_xsf_zfc}

## Determining where checks run {#checks-policies-working-with__section_p2b_4zf_zfc}

Policies monitor the configuration items (CIs) that are mapped to the agent
hosts.
To determine the specific CI types to be monitored, you can create filters. For details on configuring policy filters, see [Create a service filter for a policy](https://www.servicenow.com/docs/3wtkssmaZY1oZC2y6S4djw "Configure a service filter so that the policy monitors only those services that match the filter.").

## Updating policy mappings {#checks-policies-working-with__section_lgl_fbg_zfc}

When
activating a policy, Agent Client Collector Framework maps monitored CIs to a policy. This policy mapping repeats every seven days after the initial mapping. Every 15 minutes (by default), the Agent Client Collector monitors the CMDB for any changes matching the filter conditions, and updates the mapping accordingly. To modify the frequency by which mapping between the CMDB and CI is updated, modify the sn_agent_sync_filters_interval_min property on the System Properties page (AllSystem PropertiesAll Properties).

*[\>]: and then