These docs cover Pulse Endpoint (paid). Pulse Lite is the free, local-only build — features such as Splunk integration, MDM deployment, the CLI, upload, and licensing don't apply to it. Compare editions →

MDM Deployment

Deploy Pulse Endpoint configuration via MDM using a Configuration Profile targeting the com.qlabs.pulse preference domain.

Jamf JSON SchemaExample .plistLaunchAgent PKGUninstaller PKG

Jamf Pro

Navigate to Computers → Configuration Profiles → Application & Custom Settings → External Applications → Add → Custom Schema. Upload the JSON schema above.

Automated Deployment

A fully automated deployment requires two things: launching the app at login and auto-starting monitoring once the app is running.

Launch Pulse Endpoint at Login

Install the LaunchAgent PKG alongside the main Pulse Endpoint PKG to launch the app automatically when the user signs in. Alternatively, have users add Pulse Endpoint manually under System Settings → General → Login Items.

Silently approve Login Items via MDM (Required for 1.0b6+)

Pulse 1.0b6 registers its root helper daemon via SMAppService, which means macOS shows a "Background Item Added" notification and requires the user to approve Pulse Endpoint in System Settings → General → Login Items before the daemon can spawn. For fleet deployments, push a Managed Login Items configuration profile so the approval happens silently.

Use PayloadType = com.apple.servicemanagement and PayloadScope = System. The recommended configuration is a single Team-Identifier rule — it approves the app, the LaunchAgent, and the root helper daemon in one line, and keeps working when Pulse re-registers its helper during upgrades or self-repair:

Recommended: single Team-Identifier rule
<key>PayloadType</key>
<string>com.apple.servicemanagement</string>
<key>PayloadScope</key>
<string>System</string>
<key>Rules</key>
<array>
    <dict>
        <key>RuleType</key>
        <string>TeamIdentifier</string>
        <key>RuleValue</key>
        <string>W689L3M62P</string>
    </dict>
</array>

If your security policy requires tighter scoping, list each component explicitly — three rules, one per login item. Do not rely on the app rule alone to cover the helper daemon: BTM's parent-to-child approval cascade is not reliable when the daemon re-registers (for example after an app upgrade or Pulse's own registration self-repair), and devices can end up showing an "Enable" prompt for process collection.

Alternative: scoped rules (three entries)
<key>PayloadType</key>
<string>com.apple.servicemanagement</string>
<key>PayloadScope</key>
<string>System</string>
<key>Rules</key>
<array>
    <dict>
        <key>RuleType</key>
        <string>BundleIdentifier</string>
        <key>RuleValue</key>
        <string>com.qlabs.pulse</string>
        <key>TeamIdentifier</key>
        <string>W689L3M62P</string>
    </dict>
    <dict>
        <key>RuleType</key>
        <string>Label</string>
        <key>RuleValue</key>
        <string>com.qlabs.pulse.helper</string>
        <key>TeamIdentifier</key>
        <string>W689L3M62P</string>
    </dict>
    <dict>
        <key>RuleType</key>
        <string>Label</string>
        <key>RuleValue</key>
        <string>com.qlabs.pulse.agent</string>
        <key>TeamIdentifier</key>
        <string>W689L3M62P</string>
    </dict>
</array>
  • The app is matched by BundleIdentifier; the helper daemon and the LaunchAgent are launchd jobs and must be matched by Label — a BundleIdentifier rule for a launchd label matches nothing.
  • If you build this payload in your MDM's UI (e.g. Jamf's Login Items payload) rather than uploading the XML, double-check the rule type dropdowns: the daemon and agent entries must be Label rules, not Bundle Identifier rules.
Note: Profiles installed by double-clicking a .mobileconfig file do not always set the BTM managed flag. Push the profile via your actual MDM (Jamf, Kandji, Intune, Mosyle, etc.) for the silent-approval effect. Verify with sfltool dumpbtm — entries should show flags: ...managed....

FAQ Deployment Scenarios

Deploy and monitor continuously with Splunk

Fully automated — Pulse Endpoint launches at login, starts collecting immediately, and forwards everything to Splunk. No user interaction required.

Step 1: Install Pulse Endpoint

Deploy the Pulse Endpoint PKG and the LaunchAgent PKG via your MDM.

Step 2: Deploy MDM Configuration Profile

Create a profile for com.qlabs.pulse with these keys:

MDM Profile Keys
<key>autoStart</key>
<true/>
<key>uploadEnabled</key>
<true/>
<key>hecEndpoint</key>
<string>https://splunk.example.com:8088/services/collector/event</string>
<key>hecToken</key>
<string>YOUR-HEC-TOKEN</string>
<key>splunkIndex</key>
<string>main</string>

Result

On next login, Pulse Endpoint launches automatically, begins collecting metrics, and uploads to Splunk every 5 minutes. No user interaction needed.

Time-limited troubleshooting session (e.g. 8 hours)

A user reports performance issues. Deploy Pulse Endpoint to capture 8 hours of data, then automatically stop. Data flows to Splunk for analysis.

Step 1: Install Pulse Endpoint

Deploy the Pulse Endpoint PKG and the LaunchAgent PKG via your MDM.

Step 2: Deploy MDM Configuration Profile

Create a profile for com.qlabs.pulse with these keys:

MDM Profile Keys
<key>autoStart</key>
<true/>
<key>captureDurationMinutes</key>
<integer>480</integer>
<key>uploadEnabled</key>
<true/>
<key>hecEndpoint</key>
<string>https://splunk.example.com:8088/services/collector/event</string>
<key>hecToken</key>
<string>YOUR-HEC-TOKEN</string>
<key>splunkIndex</key>
<string>main</string>

Result

Pulse Endpoint launches, collects for exactly 8 hours, uploads to Splunk, then stops automatically. Remove the profile when done.

Silent/headless deployment with Splunk

Background-only monitoring with no menu bar icon or UI. Users never see Pulse Endpoint — it collects and uploads silently.

Step 1: Install Pulse Endpoint

Deploy the Pulse Endpoint PKG and the LaunchAgent PKG via your MDM.

Step 2: Deploy MDM Configuration Profile

Create a profile for com.qlabs.pulse with these keys:

MDM Profile Keys
<key>autoStart</key>
<true/>
<key>headlessMode</key>
<true/>
<key>uploadEnabled</key>
<true/>
<key>hecEndpoint</key>
<string>https://splunk.example.com:8088/services/collector/event</string>
<key>hecToken</key>
<string>YOUR-HEC-TOKEN</string>
<key>splunkIndex</key>
<string>main</string>

Result

Pulse Endpoint runs entirely in the background. No menu bar icon, no popover, no dashboard. Metrics are collected and forwarded to Splunk silently.

Monitor a specific app across your fleet

You're evaluating a new app and want to measure its real CPU, memory, network, and disk impact across every Mac. Use watched processes to track it.

Step 1: Install Pulse Endpoint

Deploy the Pulse Endpoint PKG and the LaunchAgent PKG via your MDM.

Step 2: Deploy MDM Configuration Profile

Create a profile for com.qlabs.pulse with these keys:

MDM Profile Keys
<key>autoStart</key>
<true/>
<key>uploadEnabled</key>
<true/>
<key>hecEndpoint</key>
<string>https://splunk.example.com:8088/services/collector/event</string>
<key>hecToken</key>
<string>YOUR-HEC-TOKEN</string>
<key>splunkIndex</key>
<string>main</string>

Step 3: Start monitoring with watched process via MDM script

Run this command on target machines (via MDM script or SSH):

Shell Command
/usr/local/bin/pulse --start --watch "AppName"

Matching is case-insensitive exact match by default (windowserver matches WindowServer). You can watch multiple processes:

/usr/local/bin/pulse --start --watch "Slack" --watch "zoom.us"

A trailing * matches by prefix, which is useful for product families that ship several helper processes under one name — for example CrowdStrike Falcon:

/usr/local/bin/pulse --start --watch "com.crowdstrike.falcon*"

This matches com.crowdstrike.falcon.Agent, com.crowdstrike.falcon.App, and com.crowdstrike.falcon.UserAgent as one aggregated watch. There are no mid-string wildcards, and an empty string or bare * matches nothing. Watched processes now include root daemons and security agents, visible via the privileged helper — not just processes owned by the console user.

Persistence and MDM precedence

CLI --watch values persist across restarts until cleared with pulse --clear-watch (combine with --start to clear and immediately start a new watch list in one command). If watchedProcesses is set via MDM, it always takes precedence over CLI --watch — the same matching rules (case-insensitive, trailing *) apply whichever surface sets it.

Result

Each watched pattern is sent to Splunk as a separate event with event_type: "watched_process", including CPU, memory, network, and disk metrics. A pattern with zero matching processes still emits an event every collection interval with watched.process_count: 0 — so you can alert when a security agent like CrowdStrike stops running, not just when it's consuming resources. Query in Splunk with:

index=main sourcetype="macos:pulse" event_type="watched_process" | stats avg(watched.cpu_percent) by hostname, watched.process_pattern
Alert when a security agent isn't running
index=main sourcetype="macos:pulse" event_type="watched_process" watched.process_pattern="com.crowdstrike.falcon*" watched.process_count=0
ConfigurationCLI Reference