Managing the Kibana service controls when dashboards, saved objects, and API endpoints are reachable, when configuration changes take effect, and how quickly the web UI is restored during maintenance windows or incident response.
Current Debian and RPM packages install Kibana as the kibana.service systemd unit. The packaged service starts /usr/share/kibana/bin/kibana, reads settings from /etc/kibana/kibana.yml, accepts environment overrides through /etc/default/kibana or /etc/sysconfig/kibana, and sends its default stdout logs into the systemd journal.
Fresh secured installs can reach a preboot interactiveSetup state while Kibana waits for valid Elasticsearch connection settings or an enrollment flow, so active (running) does not always mean the browser UI is fully ready yet. Package installs can also start with the service disabled at boot, and a password-protected Kibana keystore requires KBN_KEYSTORE_PASSPHRASE_FILE or KEYSTORE_PASSWORD so systemd can unlock it non-interactively.
Related: How to install Kibana on Ubuntu or Debian
Related: How to install Kibana on CentOS, RHEL, or Fedora
Related: How to check Kibana status
$ sudo systemctl status kibana.service --no-pager --lines=0 | head -n 10
● kibana.service - Kibana
Loaded: loaded (/usr/lib/systemd/system/kibana.service; disabled; preset: enabled)
Active: active (running) since Thu 2026-04-02 13:59:24 UTC; 8s ago
Docs: https://www.elastic.co
Main PID: 123 (node)
Tasks: 11 (limit: 14335)
Memory: 633.2M (peak: 633.9M)
CPU: 8.791s
CGroup: /system.slice/kibana.service
The Loaded line shows the current boot-start state separately from the vendor preset, so disabled; preset: enabled still means the service will not start automatically on the next boot.
On a fresh secured install, the current official package docs also note that systemctl status kibana can show the setup URL and six-digit verification code while Kibana waits for enrollment.
$ sudo systemctl start kibana.service
No output indicates the start request was accepted, but a failed start still requires a follow-up status or journal check.
If the Kibana keystore is password-protected, configure KBN_KEYSTORE_PASSPHRASE_FILE or KEYSTORE_PASSWORD in the service environment before starting so systemd can unlock the keystore without an interactive prompt.
Related: How to create a Kibana keystore
$ sudo systemctl stop kibana.service
Stopping the service makes the Kibana web UI and API unavailable until the service starts again.
$ sudo systemctl restart kibana.service
If a unit override under /etc/systemd/system/kibana.service.d/ changed, run sudo /bin/systemctl daemon-reload before the restart so systemd reads the updated unit definition.
$ sudo /bin/systemctl daemon-reload $ sudo systemctl enable kibana.service Created symlink /etc/systemd/system/multi-user.target.wants/kibana.service → /usr/lib/systemd/system/kibana.service.
Elastic's current package instructions run daemon-reload before the first enable, and the same command is required again after unit or drop-in changes.
$ sudo systemctl disable kibana.service Removed "/etc/systemd/system/multi-user.target.wants/kibana.service".
Disabling changes only the next-boot behavior. Use sudo systemctl disable --now kibana.service when the service should be disabled and stopped in one command.
$ sudo journalctl -u kibana.service --since "10 min ago" --no-pager | grep -E -m 4 'Started kibana.service|Kibana is starting|http server running|interactiveSetup' Apr 02 13:59:24 host systemd[1]: Started kibana.service - Kibana. Apr 02 13:59:26 host kibana[123]: [2026-04-02T13:59:26.741+00:00][INFO ][root] Kibana is starting Apr 02 13:59:31 host kibana[123]: [2026-04-02T13:59:31.380+00:00][INFO ][http.server.Preboot] http server running at http://localhost:5601 Apr 02 13:59:31 host kibana[123]: [2026-04-02T13:59:31.429+00:00][INFO ][preboot] "interactiveSetup" plugin is holding setup: Validating Elasticsearch connection configuration…
The current logging defaults write to stdout, so the packaged systemd unit captures those logs in journald unless file or rolling-file appenders were configured in /etc/kibana/kibana.yml.
Use sudo journalctl -u kibana.service --since "10 min ago" --no-pager for the unfiltered journal view, or sudo journalctl -fu kibana.service to follow new log lines live until interrupted with Ctrl+C.
Related: How to set Kibana logging levels
Related: How to connect Kibana to Elasticsearch
$ systemctl is-active kibana.service active $ systemctl is-enabled kibana.service disabled
active plus enabled means Kibana is running now and set to start again after a reboot, while active plus disabled means it is running now but will stay stopped after the next reboot until it is started manually.