How to configure a Logstash HTTP output

Routing Logstash events to an HTTP endpoint makes it possible to hand structured data directly to webhook receivers, ingestion APIs, and custom services without adding a broker or queue in between.

The http output plugin sends each completed event as an HTTP request and lets the pipeline define the target url, required http_method, body format, custom headers, and TLS settings. Adding an explicit output id also makes the plugin easier to identify in Logstash node statistics when the pipeline has multiple outputs.

Duplicate-sensitive endpoints need deliberate retry settings because current plugin-level retries can continue indefinitely on retryable HTTP failures, and older examples that still use removed SSL option names such as cacert fail on current plugin releases. Keep API tokens in the Logstash keystore or service environment instead of the pipeline file, and confirm both the Logstash output metrics and the receiver's own request history before treating the route as production-ready.

1. Check whether the http output plugin is already available in the current Logstash installation.

   $ sudo /usr/share/logstash/bin/logstash-plugin list --verbose logstash-output-http
   Using bundled JDK: /usr/share/logstash/jdk
   logstash-output-http (6.0.0)

   Logstash packages bundle many common plugins. If the list is empty, install the plugin with sudo /usr/share/logstash/bin/logstash-plugin install logstash-output-http before continuing.

2. Create a dedicated example input path that the logstash service account can read.

   $ sudo install -d -o logstash -g logstash -m 0750 /var/lib/logstash/examples
   $ sudo install -o logstash -g logstash -m 0640 /dev/null /var/lib/logstash/examples/http-output.log

   The example uses a separate file input so the output can be tested without touching production pipelines that already read application or system logs.

3. Create a pipeline configuration file at /etc/logstash/conf.d/60-http-output.conf.

   input {
     file {
       path => ["/var/lib/logstash/examples/http-output.log"]
       start_position => "end"
       sincedb_path => "/var/lib/logstash/http-output-demo.sincedb"
       tags => ["http_output_demo"]
     }
   }
   
   output {
     if "http_output_demo" in [tags] {
       http {
         id => "http_demo_output"
         url => "https://receiver.example.net/logstash"
         http_method => "post"
         format => "json"
         headers => {
           "X-Logstash-Pipeline" => "http_demo_output"
         }
         automatic_retries => 1
         retry_failed => false
         socket_timeout => 10
         request_timeout => 30
       }
     }
   }

   Replace https://receiver.example.net/logstash with the real destination endpoint. Set retry_failed back to true only when the receiver can safely handle repeated requests or deduplicate them.

   Use current ssl_… option names for HTTPS validation, such as ssl_certificate_authorities. Legacy settings such as cacert now cause the output plugin to fail at startup.

   Related: How to create a Logstash keystore How to add a secret to a Logstash keystore

4. Test the pipeline configuration with the packaged settings directory and a temporary data path.

   $ sudo -u logstash /usr/share/logstash/bin/logstash --path.settings /etc/logstash --path.data /tmp/logstash-configtest --config.test_and_exit -f /etc/logstash/conf.d/60-http-output.conf
   Using bundled JDK: /usr/share/logstash/jdk
   ##### snipped #####
   [2026-04-07T08:53:15,632][INFO ][logstash.javapipeline    ][main] Pipeline `main` is configured with `pipeline.ecs_compatibility: v8` setting. All plugins in this pipeline will default to `ecs_compatibility => v8` unless explicitly configured otherwise.
   Configuration OK
   [2026-04-07T08:53:15,633][INFO ][logstash.runner          ] Using config.test_and_exit mode. Config Validation Result: OK. Exiting Logstash

   Current Logstash releases reject superuser runs unless allow_superuser is explicitly enabled, so the configuration test is safest under the logstash account.

   Related: How to test a Logstash pipeline configuration

5. Restart the Logstash service to load the updated pipeline.

   $ sudo systemctl restart logstash

   Restarting the service restarts every active pipeline in the instance, which can briefly pause ingestion while inputs and outputs reopen.

   Related: How to manage the Logstash service with systemctl in Linux

6. Confirm the Logstash service is running after the restart.

   $ sudo systemctl status logstash --no-pager
   ● logstash.service - logstash
        Loaded: loaded (/usr/lib/systemd/system/logstash.service; enabled; preset: enabled)
        Active: active (running) since Tue 2026-04-07 08:54:03 UTC; 4s ago
      Main PID: 23144 (java)
         Tasks: 99 (limit: 28486)
        Memory: 1.0G (peak: 1.0G)
   ##### snipped #####

   Related: How to manage the Logstash service with systemctl in Linux

7. Append a test line to the example input file so the pipeline has a new event to send.

   $ printf 'http-output-test %s\n' "$(date -Iseconds)" | sudo tee -a /var/lib/logstash/examples/http-output.log
   http-output-test 2026-04-07T12:34:56+00:00

   With start_position set to end, append the test line after the pipeline is running so the file input treats it as new data.

8. Check the Logstash node statistics for the named http output.

   $ curl -s http://localhost:9600/_node/stats/pipelines?pretty | grep -nA4 '"id" : "http_demo_output"'
   92:          "id" : "http_demo_output",
   93-          "events" : {
   94-            "out" : 1,
   95-            "in" : 1,
   96-            "duration_in_millis" : 320

   A rising events.out value shows that Logstash handed events to the named HTTP output plugin. Confirm the receiver also recorded the request and returned the expected status code before relying on the path in production.

   The Logstash Monitoring API commonly listens on http://localhost:9600/ when enabled.