> ## Documentation Index
> Fetch the complete documentation index at: https://docs.iru.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Device Check In

> Learn how device check-in works for MDM and the Iru Agent. Understand check-in intervals, triggers, and how devices communicate with Iru Endpoint.

This guide applies to all device platforms

### About Device Check-In

Iru Endpoint uses different check-in mechanisms depending on the device platform. Each platform has specific check-in types that serve different purposes and occur at various frequencies. Understanding these check-ins helps you track device state, enforce policies, and ensure applications are deployed reliably.

> [!NOTE]
>
> As of **April 8, 2026**, apps were updated from **Kandji** ![](https://mintcdn.com/iru/20OhJ3wZmF4DKbOd/assets/media/images/kandji-bee-light-icon.png?fit=max\&auto=format\&n=20OhJ3wZmF4DKbOd\&q=85\&s=3ac73eb9098c090ac2838a4902a70e35) to **Iru** ![](https://mintcdn.com/iru/8j4H0SpqtcKJ5JUM/assets/media/svgs/Iru-Logomark-OnLight-16-Dashboard.svg?fit=max\&auto=format\&n=8j4H0SpqtcKJ5JUM\&q=85\&s=befa6ce99e1df18d397deb65aec8edaf) branding. App names changed from **Kandji Self Service** to **Iru Self Service** and from **Kandji Agent** to **Iru Agent**. The manual enrollment portal now uses Iru branding. Please update **scripts, automations, and utilities** that still reference the old app names.

### How It Works

Device check-ins are the communication mechanism between managed devices and Iru Endpoint servers. They enable:

* Policy enforcement and compliance monitoring
* Application deployment and updates
* Device inventory collection
* Configuration profile management
* Real-time device management commands

The check-in frequency and mechanism vary by platform, with some using agent-based check-ins and others relying on MDM push notifications.

### Platform-Specific Check-In Details

**macOS**

### Recurring Check-In

**Frequency:** Every 15 minutes\
**Mechanism:** Iru Agent

This check-in ensures that the Iru Agent is up-to-date, executes and enforces Blueprint parameters, and installs any pending Library Items such as custom scripts, printers, apps, and auto apps. Each item has a specific timeout period for installation.

#### Order of Operations and Timeouts

Library Items are processed in a specific sequence. Each type of Library Item is handled in an alphanumeric order, with uppercase letters taking precedence over lowercase ones. The timeout values define the maximum time allowed for each Library Item to complete its installation or execution before it is stopped. Additionally, each run is governed by a global timeout limit of 12 hours, which also applies to installations of Custom Apps and Apps and Books initiated through Self-Service.

| **Priority** | **Operation** | **Timeout** |
| - | - | - |
| 1 | Custom Scripts | 1 hour per item |
| 2 | Custom Printers | 3 hours per item |
| 3 | Custom Apps | 12 hours (global limit) |
| 4 | Auto Apps | 6 hours per item |
| 5 | Managed OS | 12 hours (global limit) |

#### Forcing a Recurring Check-In

To force a recurring check-in, run the following command in Terminal:

```bash theme={null}
sudo iru run
```

### Daily Check-In

**Frequency:** Every 24 hours\
**Mechanism:** Iru Agent

This check-in includes all recurring check-in items and additional daily items like custom scripts, compliance scripts, and Blueprint parameters. It also involves securing home folders, checking application and system folders for appropriate permissions, and collecting daily computer information for submission to the Iru Endpoint tenant. The daily check-in follows the same sequence as the recurring one, starting after executing Blueprint Parameters. Once all Library Items are completed, the application inventory is sent back to Iru Endpoint.

#### Forcing a Daily Check-In

To force daily check-in, run the following command in Terminal:

```bash theme={null}
sudo iru run --reset-daily
```

This also reruns daily Blueprint Parameters, daily Custom Scripts, and application inventory (including MDM commands), even if they already ran in the last 24 hours. To force a single Library Item, use `sudo iru library --item <name or ID> --reset-daily`. See [Iru Agent Command Line Interface](/en/endpoint/agent/iru-agent-command-line-interface.md).

A daily check-in can also be forced using the sync button in Self Service:

**1. Open Self Service**

Open the **Iru Self Service** app.

**2. Navigate to Device Info**

Navigate to the **Device Info** section on the left.

**3. Select Sync**

Select **SYNC**.

### MDM Daily Check-In

**Frequency:** Every 24 hours\
**Mechanism:** Apple Push Notification service (APNs) / MDM framework

This check-in involves executing the following MDM commands to update device information:

* ProfileList
* InstalledApplicationsList
* SecurityInfo
* CertificateList
* AvailableOSUpdates
* DeviceInformation

#### Forcing an MDM Daily Check-In

From the Iru Web App, select **Perform daily check-in** in the **Device Action Menu**. On Mac computers, this runs the MDM items listed above. It does not run the Iru Agent daily check-in.

**1. Navigate to Device Record**

Navigate to the **Device Record** in the Iru Web App.

**2. Open Device Action Menu**

Open the **Device Action Menu** (ellipsis).

**3. Select Perform daily check-in**

Select **Perform daily check-in**.

You can also force the daily MDM commands in Terminal:

```bash theme={null}
sudo iru update-mdm
```

### MDM Commands & Profiles

**Frequency:** Instant\
**Mechanism:** APNs / MDM Framework

This check-in allows for instant execution of any MDM command, such as wiping a device, setting a device name, or installing applications. It also includes any profile deployed via a Library Item.

#### How Instant is MDM Communication?

MDM servers send a unique notification to the Apple Push Notification service, prompting managed devices to check in with their MDM server. Apple devices regularly poll APNs for these notifications, enabling almost immediate management of devices that are online. Consequently, there isn't a set check-in time for MDM commands, nor is there a way to enforce a check-in.

**Windows**

### Recurring Agent Check-In

**Frequency:** Every 15 minutes\
**Mechanism:** Iru Agent

The Iru Agent checks in every 15 minutes for app inventory, app deployment, and PowerShell scripts. The agent also keeps itself up to date.

During a recurring check-in, the Iru Agent:

* Installs or updates assigned apps
* Runs assigned PowerShell scripts
* Submits application inventory to Iru Endpoint
* Updates the agent to a newer version if available

MDM-delivered policies, including Windows Firewall and BitLocker, are not driven by this interval. See [Event-Driven MDM Commands](#event-driven-mdm-commands) and [MDM Daily Check-In](#mdm-daily-check-in) below.

### Event-Driven MDM Commands

**Frequency:** Generally within a couple of minutes\
**Mechanism:** Windows Push Notification Services (WNS) / MDM Framework

New policies and settings changes from an admin are event-driven. When you save a change in the Iru Endpoint Web App, the request is sent via WNS. On online devices, enforcement generally happens within a couple of minutes.

This includes MDM system policies (including Windows Firewall and BitLocker) and commands such as wipe or retire. There's no fixed check-in interval for event-driven delivery; timing depends on device connectivity and WNS availability.

### MDM Daily Check-In

**Frequency:** Every 24 hours\
**Mechanism:** MDM

If a user manually changes something on the device (for example, local firewall settings), that drift is remediated on the daily MDM check-in. The daily check-in evaluates targeted policies against admin intent, remediates as needed, and collects daily device information (system info, hardware inventory, policy status).

#### Forcing an MDM Daily Check-In

The Device Action menu uses the same **Perform daily check-in** command on Windows. This sends an MDM check-in. It pushes down MDM policies that were waiting to deploy. It does not remediate policies that have already been applied, and it does not force an Iru Agent sync.

**1. Navigate to Device Record**

Navigate to the **Device Record** in the Iru Web App.

**2. Open Device Action Menu**

Open the **Device Action Menu** (ellipsis).

**3. Select Perform daily check-in**

Select **Perform daily check-in**.

### Logs

* **Iru Agent Logs**: `%ProgramData%\kandji\agent\logs`
* **Windows MDM Logs**: Event Viewer → **Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider (Admin)**

Use these logs to validate whether check-ins occurred and to identify failures in MDM or Agent processing.

**iOS, iPadOS, tvOS, visionOS**

### How is MDM Communication Instant?

MDM servers send a particular type of notification to request managed devices to "Check in" with their MDM server. As part of Apple Push Notification service (APNs), Apple devices constantly poll Apple Push Notification service for **Notifications**. This results in near-instant management of online devices; as such, there is no defined "Check-in" time for MDM commands.

### MDM Daily Check-In

**Frequency:** Every 24 hours\
**Mechanism:** Apple Push Notification service/MDM framework\
**Description:** A combination of the following MDM commands automatically initiated by Iru Endpoint:

* ProfileList
* InstalledApplicationsList
* CertificateList
* AvailableOSUpdates
* DeviceInformation

#### Forcing the MDM Daily Check-In

From the Iru Web App, select **Perform daily check-in** in the **Device Action Menu**. On Apple devices, this runs the MDM items listed above.

**1. Navigate to Device Record**

Navigate to the **Device Record** in the Iru Web App.

**2. Open Device Action Menu**

Open the **Device Action Menu** (ellipsis).

**3. Select Perform daily check-in**

Select **Perform daily check-in**.

You can also request a Device Information refresh from the device record:

**1. Navigate to Device Record**

Navigate to the device record in your Iru Endpoint tenant.

**2. Select Details Tab**

Select the **Details** tab. For more on the fields shown there, see [Device Record Details](/en/endpoint/devices/device-record-management/device-record-details.md).

**3. Update Device Information**

Select **Update Now** under Device Information.

### MDM Commands & Profiles

**Frequency:** Instant\
**Mechanism:** Apple Push Notification service/MDM framework\
**Description:** Any MDM command, including:

* EraseDevice
* BlankPush
* DeleteUser
* SetDeviceName
* UnlockUserAccount
* InstallApplication
* InstallProfile

**Able to be Forced?** No

### Installed Application List

**Frequency:** Every 24 hours\
**Mechanism:** Apple Push Notification service/MDM framework\
**Description:** An MDM command:

* InstalledApplicationList

#### Forcing the Installed Application List Daily Check-In

**1. Navigate to Device Record**

Navigate to the device record in your Iru Endpoint tenant.

**2. Select Apps Tab**

Select the **Apps** tab.

**3. Update Application List**

Select **Update Now** under the Last updated section.

**Android**

### Event-Driven Status Reports

**Frequency:** Near real-time (within seconds)\
**Mechanism:** Google Pub/Sub notifications via Android Management API

Android devices use an event-driven check-in system that's completely reliant on device status reports. When changes occur on the device, the device automatically reports these state changes to Google, who then relays the information to Iru Endpoint via [Pub/Sub notifications](https://developers.google.com/android/management/notifications). This mechanism works similarly to Apple's Declarative Device Management status reports, providing near real-time updates as changes happen.

#### Pub/Sub Notification System

The Android Management API uses Google Cloud Pub/Sub to deliver device notifications to Iru Endpoint. When something changes on an Android device, Google receives that information and immediately sends it to Iru Endpoint through Pub/Sub.

This approach works well because Pub/Sub is designed to handle large volumes of messages reliably. If there's a temporary network issue, Pub/Sub will keep trying to deliver the notification until it reaches Iru Endpoint. Google also batches multiple device events together when they happen close together, which makes the system more efficient.

The result is that you get near real-time updates about what's happening on your Android devices - app installations, policy changes, security updates, and other important events all show up in Iru Endpoint within seconds of occurring on the device.

#### What Gets Reported

Android devices automatically report various state changes including:

* Application installations and updates
* Device configuration changes
* Security posture updates

#### Event-Driven Benefits

The Android event-driven approach offers several advantages:

* **Immediate Response**: Device changes are reported as they happen, providing near real-time visibility
* **Efficient Resource Usage**: Only reports actual changes rather than periodic status queries
* **Reliable Delivery**: Pub/Sub ensures notifications reach Iru Endpoint even during network interruptions
* **State change capture**: Captures all significant device state changes automatically

> [!NOTE]
>
> Android check-ins are event-driven and provide near real-time updates through Google's Pub/Sub notification system. This approach ensures immediate visibility into device changes without requiring manual check-in commands.

### Troubleshooting Check-In Issues

If devices aren't checking in as expected, see our [Troubleshooting Agent Check-In](/en/endpoint/devices/device-check-in/troubleshooting-agent-check-ins.md) guide for platform-specific troubleshooting steps.

### Best Practices

> **Monitor Check-In Status**
>
> Regularly monitor device check-in status to identify issues early and ensure policy compliance.

> **Understand Platform Differences**
>
> Be aware that different platforms use different check-in mechanisms and frequencies.

> **Use Force Check-In Sparingly**
>
> Force check-ins only when necessary, as they can impact device performance and battery life.

> **Review Logs Regularly**
>
> Check agent and MDM logs to identify patterns in check-in failures or delays.
