Objective
To explain the operational differences, schedules, retry logic, and log representations for Automox Agent Check-Ins and Device Scans.
Overview
The Automox Agent relies on two primary background processes to maintain connectivity and collect device state: Check-Ins and Device Scans. While Check-Ins serve as a lightweight heartbeat to confirm availability and receive pending commands, Device Scans perform deep inventory gathering and evaluate policy compliance.
Check-Ins vs. Device Scans Comparison
| Feature / Attribute | Agent Check-In | Device Scan |
| Primary Purpose | Device heartbeat, reachability status, and pending command polling. | Full software/hardware inventory collection and policy compliance evaluation. |
| Data Transmitted | Device uptime, agent version, timezone offset. | OS build/version, IP/hardware details, installed packages, pending patches, reboot status, Worklet compliance. |
| Default Frequency | Hourly (plus randomized jitter) and upon service startup or timezone change. | Every 6 to 24 hours (configured in Group settings) and after every device reboot. |
| System Impact | Extremely minimal (lightweight HTTP POST). | Moderate (executes local inspection scripts and queries local package managers). |
Agent Check-Ins
Trigger Conditions
An Agent Check-In occurs automatically under the following conditions:
Service Startup: Immediately when the Automox Agent service (
amagent) starts.Recurring Schedule: Once per hour (with a small randomized time variance to prevent server thundering herd issues).
System Changes: Out-of-cycle whenever a system timezone change is detected.
Retry Logic (Failure Handling)
If a Check-In fails due to network disruption or proxy issues, the agent automatically retries using exponential backoff:
Initial Retry: Starts at 1 minute between attempts.
Maximum Interval: Scales up exponentially to a maximum delay of 30 minutes until a connection is re-established.
Check-In Log Structure (amagent.log)
time=<timestamp> level=INFO msg=attempting process=checkin
time=<timestamp> level=INFO msg="performing checkin with device UUID" device_uuid=<device_uuid> process=checkin
time=<timestamp> level=INFO msg="performing request" request_type=POST url="https://api.automox.com/checkin?uptime=<uptime_seconds>&ver=<agent_version>&tz=<tz_offset>" process=checkin
time=<timestamp> level=INFO msg="response received" response="{\"id\":0,\"command\":\"nop\",\"params\":[],\"config\":{...}}" process=checkin
time=<timestamp> level=INFO msg="received command" command=nop process=checkin
time=<timestamp> level=INFO msg=complete next_in=<next_checkin_interval> process=checkinDevice Scans
Trigger Conditions
A Device Scan is initiated automatically under the following conditions:
Post-Reboot: Immediately following any system restart.
Group Scan Interval: On a recurring schedule between 6 and 24 hours, as configured in the device's assigned Group Settings.
Manual Request: When an administrator clicks Scan Device in the Automox Console.
Data Collected During a Scan
Operating system version, build number, and host details.
AWS / Cloud metadata (if running in supported cloud environments).
Installed applications, system packages, and missing/pending updates.
System reboot requirement flags.
Policy and Worklet evaluation results.
Device Scan Log Structure (amagent.log)
time=<timestamp> level=INFO msg="accepted command" command_id=<command_id> command_type=execCmd command_processor=legacy command_name=GetOS command=execCmd
time=<timestamp> level=INFO msg="executing command" start_time=<timestamp> command_id=<command_id> command_type=execCmd command_processor=legacy command_name=GetOS command=execCmd
time=<timestamp> level=INFO msg="command end" elapsed=<duration> command_id=<command_id> command_type=execCmd command_processor=legacy command_name=GetOS command=execCmd