If your Linux computer takes longer to reach the login screen than it should, the answer to why is almost certainly already sitting on your machine. A command-line utility called systemd-analyze, built into the vast majority of modern Linux distributions, can diagnose the problem in seconds without requiring any additional software.
systemd-analyze is part of the systemd suite, the init system and service manager that ships with Ubuntu, Debian, Fedora, Arch Linux, and most other mainstream distributions. According to Ubuntu's official documentation, the tool can determine boot performance statistics, retrieve state and tracing information from the system manager, and verify the correctness of unit configuration files.
Run on its own from a terminal, systemd-analyze prints a simple summary of how long the boot process took, broken into three phases: kernel initialisation, the initial RAM disk (initrd) phase, and userspace startup. That single line of output is often enough to tell you whether the problem lies in your hardware firmware, the kernel itself, or the services launched after it.
Finding the Culprit
For more granular detail, the systemd-analyze blame subcommand is where the real diagnostic work begins. It produces a ranked list of every service that ran at startup, sorted from slowest to fastest. As Linux documentation from opensource.com explains, this data can indicate which services are candidates for review or removal, though a slow service does not always mean it is the root cause of a delay; it may simply be waiting on another service to finish first.
That second scenario is where systemd-analyze critical-chain comes in. Rather than listing all services, it maps the time-critical sequence of dependent units that forms the slowest path through the boot process. Services in this chain are the ones most likely to be causing a genuine delay, and they are the logical starting point for any optimisation effort.
For those who prefer a visual overview, running systemd-analyze plot > boot.svg generates a scalable vector graphic showing every service on a horizontal timeline, with colour-coded bars representing how long each one took to start. The chart can be opened in any image viewer and makes it easy to see at a glance where time is being lost.
What to Do With the Results
Once slow services are identified, the options are straightforward. Services that are not actually needed on a given machine can be disabled using systemctl disable. Common offenders include NetworkManager-wait-online.service, which frequently appears near the top of a blame output and can often be reconfigured or replaced with a less aggressive dependency. Bluetooth services on desktop machines without Bluetooth hardware are another routine find.
It is worth being cautious before disabling anything unfamiliar. Masking a critical system service can prevent a machine from booting correctly, and testing changes on a non-production machine first is always sensible practice. The Arch Linux wiki's performance guide recommends thoroughly researching any service before disabling it and verifying system stability after each change.
The broader argument for understanding your system's boot sequence is not purely about convenience. For developers, system administrators, and businesses running Linux on workstations or servers, an unnecessarily slow boot chain often reflects accumulated service bloat: software installed over time that starts automatically without ever being actively used. Auditing startup behaviour periodically is a reasonable form of system hygiene, and systemd-analyze makes that audit genuinely accessible to anyone comfortable with a terminal.
Not every slow boot has a software fix. High firmware times may point to BIOS settings or hardware that benefits from a UEFI update. And on machines where speed is paramount, the fastest solution of all, as the Arch documentation dryly notes, is not to boot at all: suspending to RAM rather than shutting down eliminates the startup sequence entirely. But for machines that do need a full boot, the diagnostic path starts with a single command that was already there all along.