Integration Runners

The Integration Runners feature provides a centralized control plane for registering, deploying, managing, grouping, and monitoring runtime workers used to execute automation workloads.

An integration runner is a runtime worker that can be installed on a target machine and used to execute integration jobs. Runners are especially useful when automation actions need to run inside a specific network, close to internal systems, or within a controlled execution environment.

Where to find it

What this page is used for

Runners act as controlled runtime workers for automation activity. Instead of giving Logstail direct access to every internal system, a runner is installed in the environment where access is needed.

For example, a runner can be deployed in a production network where it can reach a firewall. Logstail can then use that runner to execute an approved firewall integration action.

Page Layout

The Runners page includes the following main areas:

Summary cards

The top section gives a quick operational view of the runner environment.

The 4 cards on the top right of the page are as follows:

Runner metric cards

The dashboard also shows runner metric cards such as:

These cards are useful for quick health checks before relying on automation workflows.

Runner table

The runner table lists all registered runners. Each row represents one runner and includes its current operational status and management actions.

Table columns

Runner statuses

Runner status helps determine whether a runner can execute automation jobs.

Searching and filtering runners

The page provides controls for quickly finding runners in larger environments.

Search by runner name or IP address

Use the Search runners, IP addresses field to locate a specific runner.

Example searches:

Filter by status

Use the Status dropdown to show runners by state.

Common values include:

Filter by group

Use the Group dropdown to show runners assigned to a specific runner group.

Group filtering is useful when runners are separated by:

Example groups:

Filter by operating system

Use the OS dropdown to filter runners by deployment platform.

Common values include:

This helps identify which runners are deployed on Linux/Unix systems and which are deployed on Windows systems.

Refresh runner data

Click Refresh after installing a runner, changing a runner state, or updating group assignments.

This reloads runner data and helps confirm whether a runner has checked in successfully.

Runner detail panel

Selecting a runner opens a detail panel. This panel provides runner-specific information and operational context.

The runner detail panel includes tabs such as:

Use the X button to close the panel.

Overview tab

The Overview tab displays core runner metadata.

Common fields include:

Use this tab to confirm that the runner is connected, assigned correctly, and reporting from the expected host.

Credentials tab

The Credentials tab shows the credential access available to the selected runner or its assigned group.

Credentials determine which integrations a runner is allowed to use. This is a key security control, as a runner should not automatically receive access to every integration credential.

A recommended approach is to scope credentials by group:

Jobs tab

The Jobs tab shows jobs executed by or associated with the runner.

Use this tab to review:

When troubleshooting automation, start with the Jobs tab to confirm whether the job reached the runner and whether the runner returned a successful response.

Job details and responses

Runner job details can include structured output from executed integration actions.

A job response may include fields such as:

The response area may be scrollable when the payload is large.

Use job response output to validate:

Creating a runner

The Create Runner workflow registers a new runner and generates an install command.

The workflow has two main steps:

Step 1 — Name the runner

Click Create Runner and enter a runner nickname.

Recommended naming patterns:

A good runner name should identify:

Click Create runner to register the runner in Logstail.

The button may remain disabled until a valid runner nickname is entered.

Step 2 — Install the runner

After the runner is created, Logstail moves to the install step.

Choose the deployment system that matches the target host:

The page generates a deployment command for the selected operating system.

Installing a Unix/Linux runner

Choose Unix to generate a Linux shell command.

To install a Unix/Linux runner:

Before running the Unix command, verify that:

Installing a Windows runner

Choose Windows to generate a PowerShell command.

To install a Windows runner:

Before running the Windows command, verify that:

Copying the install command

Use the Copy command button to copy the generated deployment command to the clipboard.

This reduces copy errors and helps avoid accidentally changing the command.

After the command is executed, the runner may initially appear as Pending. Click Refresh to confirm the runner has checked in and moved to an active state.

Managing runner groups

Runner groups organize runners and control credential access.

Use groups to separate execution environments by:

A runner should be added to a group before using that group for integration execution.

Creating a runner group

To create a runner group:

Example group names:

A group name should clearly describe what the group is used for.

Adding a runner to a group

After the runner is added to a group, the runner can use credentials granted to that group.

Granting credentials to a runner group

Runner groups can be edited to control which integration credentials are available to runners in that group.

To grant credentials:

Granted credentials may show both the credential name and the related integration.

Example:

pfsense-prod, pfsense

This means the pfsense-prod credential belongs to the pfSense integration and is available to the group.

Revoking credentials from a group

Use Revoke when runners in a group should no longer have access to a credential.

Revoking a credential can break jobs or playbooks that depend on it, so review active workflows before removing access.

Good reasons to revoke credentials include:

Runner actions

Each runner row includes actions for lifecycle management.

Common runner actions include:

Disable runner

Use Disable runner when the runner should temporarily stop executing jobs.

Common reasons to disable a runner:

Disabling is reversible. After disabling, the runner should not be used for execution until it is re-enabled.

Delete runner

Use Delete runner only when the runner is no longer needed.

Common reasons to delete a runner:

Recommended SOC workflow

Use the following workflow when deploying runners in a security operations environment:

Troubleshooting

Best Practices

Related Pages