How to enable Logstash pipeline reloads

Enabling automatic pipeline reloads lets Logstash apply pipeline file changes without a full service restart, which reduces ingestion pauses while you tune inputs, filters, and outputs on a live host.

When config.reload.automatic is enabled, Logstash watches the pipeline files referenced by path.config and checks them again at the interval set by config.reload.interval. On packaged Debian and RPM installs, that usually means files under /etc/logstash/conf.d. When a pipeline file changes, Logstash stops the current pipeline inputs, validates the updated configuration, initializes the replacement pipeline, and swaps it into the same JVM without a full process restart.

Automatic reload only applies to pipeline configuration changes after Logstash has already been restarted once with the setting enabled. Changes to /etc/logstash/logstash.yml, jvm.options, installed plugins, or systemd unit overrides still require a full service restart. Some plugins, such as stdin, can also block automatic reload, and current releases default allow_superuser to false, so syntax tests are safest under the logstash service account.

Steps to enable Logstash pipeline reloads:

Enable automatic reload in /etc/logstash/logstash.yml.
```
config.reload.automatic: true
config.reload.interval: 3s
```
Packaged Logstash services read /etc/logstash/logstash.yml only at startup, so you still need one service restart after saving this change. The unit qualifier is required, so use a value such as 3s or 10s rather than a bare integer.

Test the current pipeline configuration before applying the new reload setting.

$ sudo -u logstash /usr/share/logstash/bin/logstash --path.settings /etc/logstash --path.data /tmp/logstash-configtest --config.test_and_exit
Using bundled JDK: /usr/share/logstash/jdk
[2026-04-08T00:38:53,055][INFO ][logstash.runner          ] Starting Logstash {"logstash.version"=>"9.3.2", "jruby.version"=>"jruby 9.4.13.0 (3.1.4) 2025-06-10 9938a3461f OpenJDK 64-Bit Server VM 21.0.10+7-LTS on 21.0.10+7-LTS +indy +jit"}
Configuration OK
[2026-04-08T00:38:54,046][INFO ][logstash.runner          ] Using config.test_and_exit mode. Config Validation Result: OK. Exiting Logstash

Use a throwaway --path.data directory that is writable by the logstash user so the validation does not lock or dirty the live service data path under /var/lib/logstash.

Current Logstash releases block superuser runs by default, so the same check fails as root unless allow_superuser was intentionally changed.

Restart the Logstash service so it picks up the new logstash.yml settings.
```
$ sudo systemctl restart logstash.service
```
Restarting the service still pauses every active pipeline once. Automatic reload helps with later pipeline edits, but it does not remove the need for this first restart after changing /etc/logstash/logstash.yml.
Save a real change to the pipeline file you want Logstash to reload, such as /etc/logstash/conf.d/10-main.conf.
```
$ sudoedit /etc/logstash/conf.d/10-main.conf
```
Logstash reloads pipeline files under path.config. If you also changed a custom grok pattern file, save a pipeline config file too, because pattern-file changes are picked up only when a pipeline reload is triggered.

Plugins that hold OS resources open, such as stdin, can prevent automatic reload. If the pipeline does not reload after a valid file change, check the plugin mix and the service logs.
Wait at least one config.reload.interval and verify the reload counters in the node stats API.
```
$ curl -s http://127.0.0.1:9600/_node/stats/pipelines?pretty
{
  "pipelines" : {
    "main" : {
      "reloads" : {
        "last_error" : null,
        "successes" : 1,
        "last_success_timestamp" : "2026-04-08T00:40:11.261158757Z",
        "last_failure_timestamp" : null,
        "failures" : 0
      },
      "hash" : "8d1b5351cc2991466dc377a05e9f660d37eb4b8f657bb67c3781c504b510d692",
      "ephemeral_id" : "0516ab72-236a-4add-8a69-0076aa7a0397"
    }
  }
}
```
A successes value greater than 0 proves that Logstash has already reloaded this pipeline successfully. If you enabled reload but have not yet saved a real pipeline change, a successes value of 0 is still normal.

A new hash or ephemeral_id after the file change is another sign that the replacement pipeline is running.

Current Logstash 9.x releases expose reload success and failure counters under /_node/stats/pipelines. The older /_node/pipelines response still shows the current pipeline hash and ephemeral_id, but it no longer reports config_reload_automatic or config_reload_interval.

If the API is secured, use the api.http.host and api.http.port values from /etc/logstash/logstash.yml and switch the request to HTTPS or add credentials that match api.auth.type.

Review recent service logs if the reload counter stays at 0 after a real pipeline change or if last_error is populated.

$ sudo journalctl -u logstash.service --since "5 minutes ago" --no-pager | grep -E "Reloading pipeline|Pipeline started|Failed to execute action"
Apr 08 00:40:08 logstash-01 logstash[22164]: [2026-04-08T00:40:08,958][INFO ][logstash.pipelineaction.reload] Reloading pipeline {"pipeline.id"=>:main}
Apr 08 00:40:09 logstash-01 logstash[22164]: [2026-04-08T00:40:09,998][INFO ][logstash.javapipeline    ][main] Pipeline terminated {"pipeline.id"=>"main"}
Apr 08 00:40:11 logstash-01 logstash[22164]: [2026-04-08T00:40:11,252][INFO ][logstash.javapipeline    ][main] Pipeline started {"pipeline.id"=>"main"}

On packaged installs, the same reload messages also appear in /var/log/logstash/logstash-plain.log. If the reload fails, the log lines around Failed to execute action usually explain whether the problem is syntax, plugin initialization, or a resource that could not be reopened.