Authors
Emmanuel Darras
CEO & Co-founder

Kestra is now a certified Splunk partner, and the Kestra Add-on for Splunk is live on Splunkbase for Splunk Enterprise and Splunk Cloud Platform.
From now on, a Splunk alert can start a Kestra flow directly. The alert context and the search results travel with it, so the flow can fix the problem, open the ticket, ask a human to approve, and record every step.
Splunk is where many of our largest customers watch their infrastructure and security. Kestra is where they run what happens next. Over the past year, the same request kept coming back from platform, security, and operations teams, including several Fortune 500 companies: connect the two without writing glue code.
They were already doing it by hand. A script polled Splunk, an unauthenticated webhook called a flow, or an engineer read the alert and started the remediation themselves. It worked until the person who wrote the script left, or until an auditor asked who had approved the change.
One of them, running Kestra across more than a dozen industrial sites, asked us for a Splunk integration and had it in production within three days. That request is where this add-on started. Others followed, and it became clear the integration had to be a supported product, available where Splunk users already look for one.
So we joined the Splunk Build Partner Motion, put it through the Splunkbase review, and published it as an official Splunk partner.
The add-on adds a Trigger Kestra Flow alert action to Splunk. You configure it per alert, with the Kestra tenant, namespace, and flow to run. When the alert fires, the add-on calls the Kestra Executions API and sends:
$result.host$ or $name$Each value arrives in the flow as a typed input. Kestra connections are reusable across alerts, API tokens are stored encrypted in Splunk’s credential store, and a dedicated kestra_alert_user role lets alert owners use the action without admin rights.
A Splunk alert detects repeated failed logins on a production host. It triggers a Kestra flow that:
id: splunk_failed_loginsnamespace: security.response
inputs: - id: search_name type: STRING - id: host type: STRING - id: user type: STRING - id: results type: FILE
tasks: - id: log_alert type: io.kestra.plugin.core.log.Log message: "{{ inputs.search_name }}: failed logins for {{ inputs.user }} on {{ inputs.host }}"
# next: disable the account, open the incident, pause for approval, # then send the outcome back to SplunkThe same pattern covers the rest of operations: a disk filling up runs the cleanup playbook, a certificate close to expiry starts the renewal, a degraded service gets restarted, and its owner notified. Every run has an owner, an approval where one is needed, and an audit trail.
Kestra flows already work with Splunk through the Kestra plugin for Splunk in Kestra Enterprise:
Send pushes events to Splunk through the HTTP Event CollectorSearch runs an SPL query and returns the results to the flowLogExporter ships Kestra execution logs to SplunkWith the add-on, Splunk can now start those flows too. Detection lives in Splunk, response runs in Kestra, and the results flow back to Splunk, so security and operations teams keep one place to search everything that happened.
Most of the requests behind this add-on came from infrastructure teams. They use Splunk to see what happens across servers, networks, and clouds, and Kestra to automate the infrastructure itself: provisioning, patching, configuration with Ansible and Terraform, and migrations off legacy tools such as VMware vRA and vRO. The add-on closes the loop between the two.
Thank you to the Cisco and Splunk partner teams.
Stay up to date with the latest features and changes to Kestra