← Back to blog
April 30, 2026·6 min read·ARR Power

Your Homeserver Is Wasting $200/Year (And You Don't Know Why)

You know that feeling when you realize your electric bill is higher than it should be, and you can't figure out why? I had that moment last year. I'd spent mont...

A
Aleko
Building AI tools · alekotools.com

You know that feeling when you realize your electric bill is higher than it should be, and you can't figure out why? I had that moment last year. I'd spent months optimizing my homeserver setup — better cooling, efficient power supplies, the whole thing. But my electricity costs kept creeping up, and I couldn't pinpoint the culprit.

Data point
12 hours — the hidden cost
homeserver power consumption
Illustrative — patterns from talking to real users in this space

Turns out, it wasn't the server itself. It was the stuff running in the background that I'd completely forgotten about.

If you're running Radarr or Sonarr (or both), you probably know the feeling. You set them up, configure your libraries, and then... they just run. They do their thing. You check in occasionally to see if new episodes showed up, and life is good. But here's what's actually happening behind the scenes: your server is waking up your hard drives multiple times per hour to scan for new content, check for updates, clean up old files, and perform maintenance tasks. Even when you're not actively using the server. Even at 3 AM. Even when nothing has changed.

This is the hidden cost of self-hosting that nobody really talks about.

The Math That Surprised Me

Let me break down what I found when I actually looked at my logs. My Radarr instance was configured to scan for new episodes every 12 hours. Sonarr was doing the same thing. On top of that, both were running library cleanup tasks, checking for missing episodes, and syncing metadata — all on their own schedules, all independent of each other. So even though I thought I had things optimized, my drives were spinning up constantly throughout the day.

A typical 3.5-inch hard drive uses about 5-7 watts when it's actively spinning, but here's the thing: it's not just the power draw while it's running. It's the spin-up cost. Every time a drive wakes from sleep, it draws a spike of power — sometimes 10-15 watts for a few seconds. Do that 50 times a day, and you're looking at real electricity costs. Over a year, we're talking about $150-300 depending on your local rates and how many drives you have.

I know that doesn't sound like much, but it adds up. And more importantly, it's completely unnecessary.

Why This Happens (And Why It's Hard to Fix)

Radarr and Sonarr are designed to be thorough. They want to make sure you never miss a new episode. They want to keep your library clean. They want to check for updates. These are all good things. But they're not designed with power efficiency in mind — especially not for people running them on home hardware where electricity costs actually matter.

The problem is that these tools don't talk to each other. Radarr doesn't know that Sonarr is about to wake up the drives in 10 minutes. So instead of batching their tasks together, they each do their own thing on their own schedule. Your drives spin up, do one task, spin down, then spin back up 5 minutes later for the next task. It's like having multiple people in your house all taking separate trips to the kitchen instead of going together.

And the built-in scheduling options? They're pretty limited. You can set intervals, but you can't really say "run all your maintenance tasks in a single 1-hour window at 2 AM and then leave the drives alone." You're stuck with whatever the developers thought made sense.

What Actually Works

So what's the solution? The honest answer is that there's no perfect fix, but there are some things that actually help.

First, you need to understand what tasks are actually running and how often. This sounds obvious, but most people don't know. Go into your Radarr and Sonarr settings and look at the scheduled tasks. Write them down. Note the intervals. You'll probably be surprised at how many things are running and how frequently.

Second, consolidate where you can. If Radarr is scanning every 12 hours and Sonarr is scanning every 12 hours, can you change one of them to 24 hours? Probably. Will you miss an episode? Almost certainly not — most shows don't drop new episodes every 12 hours. The scanning frequency is overkill for most people.

Third, batch your tasks. This is the big one. Instead of having tasks scattered throughout the day, try to group them into a single maintenance window. Set Radarr to scan at 2 AM. Set Sonarr to scan at 2:05 AM. Set your cleanup tasks for 2:10 AM. Now your drives spin up once, do everything, and go back to sleep. Instead of 50 wake-ups per day, you might have 2 or 3.

Fourth, use sleep modes aggressively. If your server supports it, put your drives into aggressive sleep mode. Some people worry this will cause issues, but modern drives handle it fine. The spin-up time is negligible.

Fifth, monitor what's actually happening. Check your system logs. See if your drives are actually spinning down between tasks. Some people find that their drives never actually sleep because something is constantly poking them. If that's you, you need to find out what and disable it.

The Honest Limitations

I should be clear: this isn't a magic solution. You're still running these services, and they still need to do their jobs. You can't reduce power consumption to zero. And if you're the type of person who needs to know about new episodes within hours of them dropping, aggressive batching might not be for you. There's a tradeoff between responsiveness and efficiency.

Also, different setups have different constraints. If you're running on a NAS with built-in power management, you might have more control than if you're running on a custom Linux box. If you're using cloud storage or a remote library, some of this doesn't apply. The point is to understand your specific situation and optimize for it.

Why This Matters More Than You Think

Look, I get it. $200 a year isn't going to bankrupt anyone. But it's not really about the money. It's about the principle. You built a homeserver because you wanted control. You wanted to own your data. You wanted to understand how your systems work. And then you let these background tasks run wild without really thinking about it.

Optimizing your server's power consumption is just an extension of that same principle. It's about being intentional. It's about understanding what your hardware is actually doing and making conscious decisions about it instead of just accepting the defaults.

Plus, there's the wear factor. Every time your drive spins up, that's wear. Every spin-up is a tiny bit of life taken off the drive. Reduce unnecessary wake-ups, and you're extending the lifespan of your hardware. That's real value.

The Practical Next Step

Start by logging into your Radarr and Sonarr instances and actually looking at the scheduled tasks. Spend 15 minutes understanding what's running and when. Then think about whether those intervals make sense for your use case. You might find that you can cut your task frequency in half without noticing any difference in functionality.

If you want to get more sophisticated about it, there are tools that can help you batch and schedule these tasks more intelligently. I built something for this exact problem — it's a simple daemon that lets you set custom batching windows so all your maintenance tasks run together instead of scattered throughout the day. It's at https://arrpower.vercel.app if you want to check it out. But honestly, even without a tool, just understanding your current setup and making some manual adjustments will probably save you a decent chunk of money and drive wear.

The point is: your homeserver doesn't have to be inefficient. It just takes a little attention.

Built by Aleko
Try ARR Power →
Free to try · Built by Aleko, solo
Open
More from the blog
A
April 23, 2026
Your hard drive wakes up 50 times a day (and you have no idea)
S
April 30, 2026
AP Calc FRQ: The Points People Leave on the Table (Without Knowing It)
S
April 30, 2026
APUSH Period 7 Is the Most-Tested and the Most-Skipped Unit