Reload Fluent Bit Configuration Without Restarting (2026)

Reloading Fluent Bit’s configuration without a full restart is surprisingly easy, but the command you use depends entirely on how Fluent Bit was started in the first place.

Let’s see Fluent Bit in action, specifically how it picks up changes. Imagine you have a fluent-bit.conf file like this:

[SERVICE]
    Flush        1
    Daemon       off
    Log_Level    info
    Parsers_File parsers.conf

[INPUT]
    Name        tail
    Path        /var/log/myapp/app.log
    Tag         myapp.log
    Format      json

[OUTPUT]
    Name        stdout
    Match       myapp.log
    Format      json

Now, let’s say you want to change the Flush interval from 1 to 5 seconds and add a new output plugin to stderr for debugging. You’d modify the file:

[SERVICE]
    Flush        5
    Daemon       off
    Log_Level    info
    Parsers_File parsers.conf

[INPUT]
    Name        tail
    Path        /var/log/myapp/app.log
    Tag         myapp.log
    Format      json

[OUTPUT]
    Name        stdout
    Match       myapp.log
    Format      json

[OUTPUT]
    Name        stderr
    Match       *
    Format      json

If Fluent Bit is running, you can send it a signal to reload. The most common way to do this is by sending a SIGHUP signal to its process ID (PID).

First, find the PID. If you’re running Fluent Bit as a systemd service, you can often find it using systemctl status fluent-bit. Look for a line like Main PID: 12345.

If you’re running it manually, you might use ps aux | grep fluent-bit.

Once you have the PID (let’s assume it’s 12345), you can send the reload signal:

kill -HUP 12345

Within a second or two, Fluent Bit will re-read its configuration file. You should see log messages indicating it’s loading the new configuration. The Flush interval will change to 5, and you’ll start seeing output on stderr as well. This happens because the SIGHUP signal triggers Fluent Bit’s internal mechanism to re-parse its configuration file and re-initialize its plugins based on the new settings. It doesn’t stop and start threads; it gracefully reconfigures them.

The core problem Fluent Bit’s reload mechanism solves is the need to update logging configurations without interrupting data flow. Imagine a critical production system; a full restart could mean a few seconds of lost logs, or worse, a brief outage if other services depend on Fluent Bit. By allowing a signal-based reload, you can update routing rules, add new output destinations, or tweak buffer sizes on the fly.

The mental model here is that Fluent Bit, when running, maintains a set of active plugins and their configurations. When it receives a SIGHUP signal, it doesn’t just start a new process. Instead, the existing process intercepts the signal, reads the configuration file again, and then reconfigures its existing plugin instances. For plugins that support hot-reloading (most do for configuration changes), this means they update their internal state without being destroyed and recreated. For example, an output plugin might update its destination address or a parser might load new rules. The Flush interval change is a prime example: the SERVICE section is re-evaluated, and the internal timer is adjusted.

The kill -HUP <PID> command is the universal way to signal most Unix-like processes to reload their configuration. Fluent Bit is designed to honor this convention. The key is that the process must be running and in a state where it can receive and act upon signals. If Fluent Bit is running as a daemon managed by systemd, supervisord, or another process manager, the kill command will work directly on the PID of the Fluent Bit process. However, some process managers might intercept signals or have their own preferred reload mechanisms. For instance, systemd might have a systemctl reload fluent-bit command if the service unit file is configured to handle reloads.

What many people miss is that not all configuration changes are equally "hot." While changing output destinations or parsing rules usually works seamlessly, fundamental changes to the SERVICE section, like altering the Parsers_File path itself or changing the Daemon setting, might require a full restart. Fluent Bit will attempt to reload them, but the old process might not be able to adapt, leading to unexpected behavior or errors. Always consult the specific plugin’s documentation for its reload capabilities.

The next hurdle you’ll likely encounter is understanding how to manage configuration reloads in highly distributed or automated environments.