How to Speed Up Linux Boot Time: Find the Slow Service

Short answer: to speed up Linux boot time, run systemd-analyze blame to find the slowest service, then check systemd-analyze critical-chain to see whether it actually delays your login — because the two answers are often different. I measured my own Linux VM's boot on October 29, 2026: userspace finished in 3.94 seconds, yet the slowest service took 3.78 seconds. That sounds like a contradiction, and resolving it is the whole trick to fixing a slow boot without breaking anything. This guide shows you the exact commands, how to read the numbers, and which fixes are safe.

Step 1: Measure Your Boot Before Changing Anything

Never change settings before you have a baseline — otherwise you will never know what actually helped. On any modern Linux distribution that uses systemd (Ubuntu, Fedora, Debian, Arch, and most others), open a terminal and run:

systemd-analyze time

On my test machine, running systemd 255 on Ubuntu, the result was:

Startup finished in 3.941s (userspace)
default.target reached after 433ms in userspace.

Two numbers matter here. "Startup finished" is the total time userspace took to settle. "Default.target reached" is when the system was actually ready for you to log in — just 433 milliseconds in my case. That gap is the first clue: a machine can have a long total startup time and still reach the login prompt quickly, because many services keep starting in the background after you can already log in. If your login prompt is what feels slow, the second number is the one to watch, not the first.

Note: this VM reported no firmware or kernel time — cloud VMs often skip those lines; a physical PC shows them.

Step 2: Find the Slowest Services With blame

Next, list every service by how long it took to start:

systemd-analyze blame

Here is my machine's complete output, all 14 services:

The headline looks obvious: hatch-ca-trust.service at 3.78 seconds is the slowest thing on the system, taking almost the entire 3.94-second userspace time. On a typical desktop, expect culprits like NetworkManager-wait-online.service (which makes boot wait for the network), Bluetooth, modem, or snap services at the top. On this minimal VM, none of those exist — I checked, and all four are simply not installed, which is why the list is so short.

But before you rush to disable the top entry, read the next step. It changes the conclusion completely.

Step 3: Check What Actually Blocks Your Login

blame shows how long each service took, but not whether anything was waiting for it. Services start in parallel, so a slow service may finish long after you are already logged in. The command that shows the real chain of delays is:

systemd-analyze critical-chain

On my machine, the entire critical chain was:

default.target @433ms

That is it — nothing was blocking the login target beyond 433 milliseconds. So the 3.78-second service, despite topping the blame list, does not delay login at all on this machine: it is VM infrastructure (certificate trust setup) that runs in the background after the system is usable. Disabling it would not make login faster, and touching vendor infrastructure services is a good way to break something you do not understand. This is the most common mistake in boot-speed guides: they tell you to disable whatever tops blame, when the correct question is what sits on the critical chain.

On a slow desktop, the critical chain usually tells a different story — a chain like graphical.target → multi-user.target → NetworkManager-wait-online.service means boot genuinely waits for the network, and that is a real, fixable delay.

Step 4: The Safe Fixes, in Order

Apply these one at a time, reboot, and re-measure after each one. If a change makes things worse, you will know exactly which one to undo.

1. Disable services you genuinely do not use. If blame and critical-chain agree that a service is both slow and blocking — and you recognize it as something you never use, like Bluetooth on a desktop with no Bluetooth hardware — disable it:

sudo systemctl disable --now bluetooth.service

Check first what a service does with systemctl status <name> before disabling it, and never disable anything with systemd in its name, your display manager, your network manager itself, or a service you do not recognize. Disabling is reversible (systemctl enable brings it back); masking a service is harder to undo and should be a last resort. The Arch Wiki's boot performance guide gives the same general advice: measure first, then remove only what you can identify as unnecessary.

2. Stop boot from waiting for the network. If NetworkManager-wait-online.service is on your critical chain, it is usually safe to disable it on a home desktop — your desktop will appear before the network is ready, and applications will connect a moment later:

sudo systemctl disable NetworkManager-wait-online.service

Do not do this on a server that must have networking before its services start.

3. Shorten the GRUB menu timeout. On a physical PC, the boot menu typically waits 10 seconds for you to pick an operating system. Cutting it to 2 seconds saves 8 seconds of waiting on every boot — simple arithmetic, not a measured benchmark, but the saving is real because that wait happens before anything else. Edit /etc/default/grub, set GRUB_TIMEOUT=2, then run sudo update-grub. Note that this step does not apply everywhere: this test VM has no /etc/default/grub at all, because cloud VMs boot through a different path. If the file is missing on your machine, skip this step.

4. Do not chase the wrong things. Removing old kernels frees disk space, not boot time. Reinstalling your distribution will not fix a slow service — it will just reinstall the same slow service. And a stopwatch on your phone is a poor substitute for systemd-analyze: it measures everything from power button to desktop, including firmware time that no software setting can change.

What I Deliberately Did Not Do

I did not disable anything on this test machine or reboot it for a "before and after": its boot is already fast (433 ms to login) and its slowest service is VM infrastructure that does not block login. Boot changes only take effect at the next boot, so any claimed saving without a reboot has not been measured. The diagnostic numbers above are real; the savings from the fixes are yours to measure with the same two commands.

FAQ

Why is my boot slow if blame shows nothing over a second? Check critical-chain, not just blame. The delay may be firmware or kernel time (shown in systemd-analyze time on physical PCs), a GRUB timeout, or disk encryption password entry — none of which appear as a slow service.

Is it safe to disable a service from blame? Only if you know what it does, it sits on the critical chain, and you do not use it. When in doubt, look the service up in your distribution's documentation first. Disabling is reversible; deleting or masking is not always.

Does a faster boot mean a faster computer? No. Boot time measures startup only. Once you are logged in, a slow computer is usually a RAM, disk, or CPU problem, not a boot problem.

How often should I check this? Once, when boot feels slow, and again after installing software that adds startup services. Boot time creeps up gradually as services accumulate.

Conclusion

Speeding up Linux boot time is a measurement job, not a guessing game: systemd-analyze time for the baseline, blame for slow services, and — most importantly — critical-chain for which of them actually delays login. On my machine that distinction was the whole story: a 3.78-second service that delays nothing. Fix the services on the critical chain, shorten the GRUB timeout if you have one, leave what you do not recognize alone, and re-measure after every change.

How this article was made

All boot numbers were measured on October 29, 2026, on this site's Linux VM (systemd 255 on Ubuntu) using systemd-analyze time, blame, and critical-chain; the 14-service blame table above is the complete, unedited output. Service-presence and GRUB checks were run on the same machine. General fix guidance follows the systemd documentation — see the systemd-analyze manual and the Arch Wiki boot performance guide — and the Ubuntu manual page for systemd-analyze. No service was disabled and no reboot re-timing was performed on the test machine, for the reasons stated above. This article was drafted with AI assistance (Tiny, TechVerge's AI assistant) and every number in it comes from the tests described.