Running scripts from Graylog alerts with the Enterprise script notification
The Enterprise script notification runs a local script on a Graylog host when an event definition fires, so it suits a team that wants an alert to start a remediation step or a ticket helper on infrastructure it controls. It is an Enterprise feature, not part of Graylog Open, which is licensed under the Server Side Public License version 1 (SSPL-1.0), a license the Open Source Initiative does not approve. According to the Graylog pricing page, Graylog Enterprise starts at 15,000 US dollars per year with a minimum of 10 GB per day or 100 Graylog Compute Units, licensed on processed data with no per-user or per-device fees. Confirm that the license tier and minimum fit your ingest before you design around this option, because the script notification is only one of several features the tier unlocks.
Before building, decide whether a script is the right tool at all. A script runs with the privileges of the account that hosts it, so every alert that can execute code adds a path from log content to a shell on a server. Confirm with Graylog how the notification passes event fields to the script, whether values such as user names or hostnames arrive as arguments or in the environment, and how a failed or hung run is reported back to the event. Check your own environment for the script host's operating system account, its network reach and where the script's logs go, since these details are set by your deployment and not by the product page.
The points that need the most scrutiny are the security of the script host and the handling of timeouts. Run the script under a dedicated, unprivileged account, keep it on a read-only path that only administrators can change, and limit what it can reach on the network. Plan for a run that never finishes, so that a stuck script does not block alert processing or pile up duplicate remediation. If the action needs to call an automation platform or open a ticket, a webhook to that tool is often easier to authenticate, audit and retry, and the sibling topic on ticketing and SOAR webhooks covers that path in detail.
Graylog script notification compared with webhooks, chat and paging
This table compares the Enterprise script notification with HTTP and Custom HTTP notifications, Slack, PagerDuty and email. Read each row to see the edition, where the code runs, what leaves the Graylog server and the work it best fits. Confirm the exact script payload and execution limits in the current Graylog 7.2 documentation before you commit to a design.
| Option | Edition and where code runs | What leaves the Graylog server | Best fit |
|---|---|---|---|
| Script notification | Enterprise. Local script runs on a Graylog server node or host you designate | Event data passed to a local script on the host, then whatever the script sends onward | Local remediation or enrichment that must run on your own host |
| HTTP notification | Enterprise. Graylog sends the request, no code on the Graylog host | Event fields sent in a request to a fixed endpoint | Simple calls to a tool that accepts a standard HTTP request |
| Custom HTTP notification | Enterprise. Graylog sends a templated request, no code on the Graylog host | Fields selected in the template sent to the endpoint you configure | Calls to an automation tool that needs a specific payload shape |
| Slack notification | Named on the Graylog Open product page. Confirm the edition for your version | Event details formatted into a Slack message | Team awareness where responders already work in chat |
| PagerDuty notification | Named on the Graylog Open product page. Confirm the edition for your version | Event details sent to a PagerDuty service | Off-hours paging with escalation handled by PagerDuty |
| Email notification | Named on the Graylog Open product page. Confirm the edition for your version | Event details sent to mail recipients through your mail relay | Low-urgency notices and audit trails for a shared mailbox |
| Recommended check | Confirm in the Graylog 7.2 documentation which fields and limits apply | Limit fields that leave Graylog to those responders need | Choose the path after testing with sample events |
Which Graylog node runs the script in a multi-node cluster
In a multi-node cluster, the first thing to confirm is which Graylog server node actually dispatches the notification that runs your script. The multi-node guide for medium to large deployments sets up several Graylog server nodes and sets is_leader to false on the follower nodes, so only one node holds the leader role at a time. Your alert path depends on how the script notification is dispatched and on which node is handling that work when an event fires. Do not assume that the node you edited or tested from is the node that will run the script in production. Ask your Graylog administrator to confirm the dispatch behavior for your version in the Graylog multi-node installation guide and in your own test results.
The consequence is that a script installed on one node will not exist on the others. If the script lives at a path such as /opt/graylog/scripts/ on a single server, every other node will fail the same notification with a missing file error, or, worse, run an older copy of the script if the files have drifted. Failover can also move execution silently. If the leader changes, the node that now dispatches notifications may have a different script, different permissions, a different runtime or no access to the credentials the script needs. Responders may then see no alert output at all, with nothing in the event log to explain it. Plan for this by deciding where the script must exist, how it is deployed to every candidate node, and how changes are kept identical across nodes.
Test the notification from each node that could dispatch it, not only from the one you configured. For each node, trigger a test event, confirm the script ran, check the file path, owner, execute permission, runtime version and the environment variables or secrets it reads, and record the result. Repeat the test after any node replacement, leader change or configuration update. Where the script must reach an external system, verify outbound network access from every node, since firewall rules often differ between hosts. This testing is a recurring control, so schedule it with your change process rather than treating it as a one-time setup step.
Setting up a Graylog script notification safely
This sequence sets up a script notification that runs a local program from a Graylog event without giving event data a path to the shell. Each step ends with a check you can run before the alert reaches production, and the final test covers every Graylog node.
Confirm the Enterprise entitlement before building
Before you build anything, confirm with the Graylog pricing page that the edition you hold includes the script notification, and check the license installed on your cluster. Ask your Graylog contact to confirm the entitlement in writing if the license terms are unclear. Done when the script notification type appears in the notification options of an event definition in the web interface. If it does not appear, stop here, because the remaining steps depend on that feature being available.
Create a dedicated low-privilege service account
On the script host, create a separate system account for the notification. Give it no sudo rights, no membership in administrative groups, a non-login shell, and a home directory that no other service can read. Do not reuse the account that runs the Graylog server or an administrator's login. Done when
idfor the account shows only its own group and the account cannot start an interactive session withsuorsshfrom your admin workstation.Install the script with restrictive ownership
Place the script in a directory that only root can write to, and set it to be owned by root. The service account should be able to execute the file but not modify it or replace it. Keep the script out of any path that other users or deployment tools can write to. Done when
ls -lon the file and its parent directory shows root as owner, the service account lacks write permission on both, and the service account can run the script manually with a sample argument.Validate inputs and avoid shell expansion
Write the script to treat every event field as untrusted data. Check each argument against an expected format, such as an allowlist of characters or a maximum length, and exit with a clear error code when a value fails. Invoke external commands with arguments passed as separate values, without building a command string or invoking a shell. Done when you run the script by hand with a field value containing shell metacharacters, such as a semicolon followed by a command that writes a marker file, and confirm the marker file is never created.
Add the notification to a test event definition
Create a test event definition on a stream that contains only sample data, then attach the script notification to it. Confirm in your Graylog version's documentation which event fields the notification passes to the script and in what form, because the arguments define what your script must parse. Send a test event. Done when the script log shows one invocation and the values it received match the fields you expected in the event.
Check logging and exit behavior
Trigger a deliberately failing test so you can observe how Graylog handles a non-zero exit code. Review the Graylog server log on the node that ran the notification and the script's own log for both the successful and failed runs. Note whether Graylog retries the notification and whether the failure appears in the web interface. Done when each run leaves a traceable entry in the script log and the Graylog log shows the failure, so an on-call engineer could diagnose a missed run from logs alone.
Confirm timeout handling
Find the timeout behavior documented for your Graylog version, including how long a script may run and what Graylog does when the limit is reached. Test it with a deliberately slow version of the script. Done when Graylog records the timeout, moves on without blocking other notifications, and the host shows no orphaned script process after the test. If the documentation does not state the behavior, make the script finish quickly on its own and treat the timeout as a backstop only.
Repeat the test on each Graylog node
Install the same script with the same ownership, permissions and service account on every Graylog node that may run notifications. Confirm in your version's documentation which nodes execute notifications in your cluster, and repeat the test event from each one. Compare the script logs and checksums across nodes. Done when every node produces the same result for the same test event and the checksums of the script files match, so a failover does not change behavior.
Securing the script host and the event data it receives
A script run from a Graylog alert is code executing on a server, fed by data that attackers can sometimes shape. The controls below cover the account the script runs under, how event fields reach the command, where scripts live, where secrets sit, how long a run may last, and how runs are recorded.
Dedicated least-privilege account
Run the script under a dedicated local account that owns no administrative rights and cannot read the Graylog server configuration or MongoDB credentials. If the script runs as root or an admin account, any flaw in the script or in the data it handles becomes a host compromise. Confirm in the vendor documentation which operating system user the script process inherits, and test that the account cannot write to system paths or call sudo.
Input handling for event fields
Fields such as usernames, user agents, URLs and messages come from logs that an attacker may influence, so a crafted value can inject shell syntax if the script builds a command string. Pass each field as a separate argument, never through a shell, and validate it against an expected pattern before use. Confirm whether the notification sends fields as discrete arguments or interpolates them into a command line, because that decides how much validation you must write.
Read-only script deployment
Store scripts in a directory owned by root and readable, but not writable, by the account that runs them. A writable script directory lets anyone who gains a foothold on the host replace the script, and the next alert runs the replacement with the notification's privileges. Deploy scripts through your configuration management or a reviewed release process, and check file permissions and checksums as part of host monitoring.
Secrets outside scripts and notification settings
Avoid hard-coding API tokens, passwords or webhook secrets in the script file, and avoid pasting them into the notification configuration where users with edit rights can read them. Load credentials at run time from a secrets store or a root-readable file with tight permissions, and prefer short-lived tokens scoped to the single action the script performs. Confirm how the notification stores its own settings and who can view them in the web interface and API.
Bounded runtime for each script
A script that hangs, waits on a network call or loops can hold the notification path, delaying every other alert that depends on it. Wrap the script in a time limit such as the timeout command, set its own network timeouts, and make it exit with a clear status code. Confirm whether the Graylog notification enforces a timeout itself, and what happens to the triggering event when a run fails or stalls.
Central logging of every script run
Record when each run starts, its exit status, its duration and the event identifier it handled, and ship those records to a central log store, which can be Graylog itself. Redact secrets and full message bodies from the record, but keep enough detail to reconstruct what the script did. Without this trail, a misfiring script or a misused notification is hard to prove or investigate. Confirm which run details the notification records by default.
Script or webhook: choosing by situation
Keep a local script when the response must run on one specific machine inside a restricted network. Typical examples include restarting a local service, calling a tool that only that host can reach, or writing to a system on a segment with no route to a central platform. The trade-off is that the script host becomes part of your security surface and your operations. Someone has to patch it, control who can change the script, and keep it running after the person who wrote it moves on. Confirm on which host the Enterprise Script notification executes in your version, because that host is the one you must harden.
- Locality: the action depends on access that exists only from that host, such as a local agent, a privileged socket or an isolated network segment.
- Ownership: one team owns the script, its runtime, its permissions and its change history, so the host needs the same hardening as other administrative systems.
- Blast radius: the script runs with the privileges of its account, so use a dedicated low-privilege account and limit what it can change.
- Failure visibility: a failed run is easy to miss unless its output is logged and errors raise their own alert.
- Audit trail: keep script versions in source control, because the change record otherwise lives only on the host.
Check which account the script runs under, who can edit it, and whether its output is shipped somewhere outside the host.
Move to a webhook when the response touches several systems, needs an approval step, retries after failures or must leave a record outside Graylog. An automation platform such as Shuffle can hold that sequence, keep its credentials in its own store and show run history to people who never sign in to Graylog. The trade-off is another system to run and secure, plus a dependency on the endpoint being reachable at the moment an alert fires. Decide early which side owns retries and deduplication, because both sides can retry.
- Multi-system actions: one alert can open a ticket, query an asset inventory, disable an account and notify a team, which a workflow expresses more clearly than one long script.
- Approvals: a playbook can pause for a human decision before a containment step runs.
- State tracking: the automation tool records which steps succeeded, which reduces the risk of repeating actions or leaving them half done.
- Separate audit trail: run history lives in the automation platform, which helps when auditors or responders need records beyond Graylog.
- Duplicate control: the receiving side needs a way to ignore repeat deliveries for the same event, or a retry can create duplicate tickets.
Check that the Graylog nodes can reach the endpoint, how authentication is handled, and what happens to alerts while the automation tool is down. For the design details, read the sibling topic on sending Graylog alerts to ticketing and SOAR tools with webhooks.
Use Slack, PagerDuty or email when a person only needs to see the event and decide the next step. Those notifications put context in front of responders where they already work, and they avoid building automation for a step that a human must perform anyway, such as calling a customer or accepting a risk. The trade-off is that the response depends on people, so the alert design, the escalation path and the event fields carry most of the load. A well-built message gives the responder enough to act without opening Graylog first.
- Human judgment: the decision depends on context that automation cannot weigh reliably, so scripting it adds little value.
- Escalation: paging services manage on-call rotations and escalation, which a script or workflow would otherwise have to rebuild.
- Data exposure: the message leaves Graylog for a third-party service, so limit the event fields it carries.
- Edition check: confirm which notification types your Graylog edition and version include before you design around them.
- Alert fatigue: a stream of low-value pages trains responders to ignore them, so tune thresholds and priorities first.
Check which fields appear in the message, who is paged outside business hours, and whether each destination is approved for the data class involved. For configuration details, read the sibling topic on Graylog alert notifications to Slack, Microsoft Teams and PagerDuty.
Many alerts need more than one path. A common arrangement sends a message to a responder while a local script or webhook performs the step that cannot wait for a person. Keep each path to a single responsibility so that a failure in one path does not hide what the other was meant to do, and record which path handled which action. This split also makes testing simpler, because each path can be exercised on its own before the two are linked.
- Parallel paths: the responder sees the alert while automation starts containment, so neither depends on the other finishing.
- Single owner per action: assign each automated step and each notification to one team, so nobody assumes another group is handling it.
- Idempotent actions: design each automated step so that running it twice leaves the same result as running it once.
- Separate testing: test the script, the webhook and the notification independently, then test the full alert path with a non-production event.
- Shared record: write the outcome of each path back to a place the responder can see, such as the ticket that the workflow opened.
Before building, map each alert to its owner and to the action each path performs. Confirm which of those actions can be reversed if the alert turns out to be wrong.
Limits to confirm before you commit to scripts
Script notifications run code on infrastructure you operate, so their behavior depends on details that vary by Graylog version, license and deployment layout. The cards below list what to confirm with Graylog documentation or support before you build an alerting process around them.
Timeout and concurrency behavior
Confirm how long a script may run before Graylog stops waiting for it, and how many script executions can run at once when several events fire together. A slow script that blocks later notifications can hide a burst of alerts. Ask whether a timed-out process is killed, left running, or retried, and whether that behavior is documented for your exact version. Test with a deliberately slow script that mimics your worst-case alert volume.
Event fields passed to the script
Confirm which event fields reach the script, how they are encoded (for example as arguments, environment variables or a JSON body), and how long values such as messages or field lists are handled. Check how special characters and multi-value fields are represented. Your script should validate every field before using it in a shell command, because an event field may contain text that an attacker controlled upstream.
How failures reach Graylog
Confirm what Graylog records when a script exits with an error, times out, or cannot be found on the host. Find out whether the failure appears in the server log, the event history or the notification status, and whether anyone is alerted when the script itself fails. A silent failure means a missed incident, so plan a separate check that proves the script ran.
Server-side or remote execution
Confirm whether the script runs on the Graylog server node that processes the event or on a separate agent or remote host. This decides which machine needs the script, its runtime and its credentials, and which network paths must be open. If the script runs on a Graylog node, every node in a cluster needs an identical copy and an account with limited permissions.
Version and license entitlement
Confirm that the script notification is included in your Graylog edition and that your version supports it across the 7.0 to 7.2 range in your compatibility plan. Script notifications are part of the Enterprise feature set, and the entitlement should be checked against your license before design work starts. Ask for written confirmation of the supported versions, since availability can change between releases.
Behavior during node failover
Confirm what happens to in-flight script executions and pending notifications when a Graylog node stops or leadership moves to another node. Find out whether an event can be notified twice after failover, or dropped entirely. For a multi-node cluster, ask whether only the leader sends notifications and how that interacts with the follower setting. Test a node restart during an active alert.
Questions teams ask before running scripts from Graylog alerts
How much does running a script from a Graylog alert cost?
The cost starts with the Graylog license, because the Script notification is an Enterprise option. The Graylog pricing page lists Graylog Enterprise from 15,000 US dollars per year, with a minimum of 10 GB per day or 100 Graylog Compute Units, licensed on processed data with no per-user or per-device fees. Recurring costs are that license, the servers for Graylog and its backends, and the script host. The one-time cost is the build: script design, host hardening, testing and documentation. Ask any quote to separate license, infrastructure and services, and to name the Graylog edition the scope assumes. Your daily volume decides whether the minimum applies, so measure it before budgeting.
Which Graylog license do script notifications require?
Plan on Graylog Enterprise or a higher edition for the Script notification. Graylog Open is licensed under SSPL-1.0, which is not an OSI-approved open source license, and it covers the core ingest, search and dashboard functions without this paid notification. Graylog Security adds SIEM features such as risk scoring, anomaly detection, investigations, compliance packs and prebuilt threat detection content, so it only matters if you need those too. Edition features change between releases, so confirm the notification in the Graylog documentation for the exact version you run, and get written confirmation from Graylog that your chosen edition includes it before you commit to the design.
How long does a script notification build take and what drives the effort?
The duration depends on the scope, so it should come from a written plan rather than a rule of thumb. The main drivers are the number of scripts, how many event definitions trigger them, and how strictly the script host must be controlled. Effort rises when scripts take arguments from event fields and must validate them, when they call internal systems that need credentials, or when your change control requires review and a rollback path for every script. Testing adds time because you must confirm behavior under alert bursts, timeouts and failures on the Graylog nodes. Ask the partner to list each script, its trigger, its inputs and its test cases before agreeing a timeline.
What does our team need to provide before the work starts?
You need four things in place before the build begins. First, a script host, meaning a Linux server or virtual machine you control, separate from the Graylog nodes and locked down to the commands the scripts need. Second, a Graylog Enterprise license for the edition you plan to run. Third, a named owner for each script who approves changes, handles failures and decides when a script is retired. Fourth, administrator access to the Graylog web interface with rights to create event definitions and notifications, plus read access to the logs and metrics that show how alerts behaved. A change window and sample events from your environment also shorten testing.
Can our own team build and run script notifications without a partner?
Yes, if your team already runs Graylog in production and has people who can harden a Linux host, write defensive scripts and review changes with security in mind. The work needs Graylog administration skills, a secrets approach for any credential the script uses, and a process for testing alerts without flooding responders. Teams that lack these skills often succeed by keeping the first script small, documenting it and scheduling a review before adding more. A partner is useful when you need an outside review of the script host, a repeatable test method across the cluster, or help writing the runbook your on-call staff will follow.
When is a webhook to an automation tool the safer default?
Choose a webhook when the goal is to open a ticket, notify a case system or start a playbook in a tool that already handles authentication, retries and audit logging. An HTTP or Custom HTTP notification sends the event to a fixed endpoint, which keeps the Graylog server away from local execution and avoids running code on a host that holds credentials. Use a local script only when the action must happen on a machine you control, such as restarting a local service or writing a file, and you can lock down the host. Webhooks also need careful payload design, because they send event fields out of Graylog, so limit those fields to what responders need.
What goes wrong when scripts run from Graylog alerts?
The most common failures are alert storms that start many script processes at once, scripts that hang and hold resources, and credentials stored in plain text on the host. Scripts also fail when they trust unvalidated event fields, which can carry attacker-controlled text from logs into shell commands. Another risk is that a script works on one test node but behaves differently in the cluster, so confirm in the documentation for your version which Graylog node executes the notification. Set timeouts, limit concurrency, log each run with its event identifier, and test failure paths before go-live. Ask any partner how they will prove each of these controls works.
How DeployOpen scopes and delivers Graylog alert scripts
DeployOpen treats script notifications as a small piece of a larger Graylog alerting design, so the work starts with the event definitions, the data each script needs and the host that will run it. Engagements are fixed-scope, with the script, host controls and test plan agreed in writing before any build begins.
How we scope
- Map which event definitions should trigger a script and which should stay on Slack, email or a ticketing webhook
- Record the exact event fields the script will receive and confirm that no extra user or host data leaves Graylog
- Confirm the Graylog edition and license that the Enterprise Script notification requires in your environment
- Agree in writing the script host, its permissions, timeout behavior and who owns the script after handover
How we build
- Write the script to parse event fields defensively, reject malformed input and avoid building shell commands from raw alert text
- Harden the script host with a dedicated low-privilege account, restricted file permissions and outbound network limits you approve
- Test each event definition against historical data and confirm the script behaves correctly on timeout and on repeated firings
- Document configuration, script inputs, logging locations and the rollback steps for each notification in the build
How we hand over
- Deliver the script, its configuration notes and the host hardening record in version-controlled files your team can review
- Walk your operations and security staff through the test results, failure modes and how to disable a notification safely
- Provide a clear decision note comparing the script with a webhook to an automation tool for each use case in scope
- Transfer ownership of credentials, service accounts and the script repository to named people in your organization
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer if you want DeployOpen to keep the script current
- Review the script and host again when Graylog is upgraded or when the event definitions it depends on change
- Retest notifications after host patches, runtime changes or new event fields so alerts keep firing as expected
- Confirm with your team which support scope, response expectations and review cadence fit your operating model before signing
