Homeserver electricity bills have a way of creeping up even after you've done everything right — better cooling, efficient power supplies, the whole optimization checklist. The culprit is rarely the server itself. It's the background tasks you configured once and then forgot about.
If you're running Radarr or Sonarr (or both), the setup feels seamless: configure your libraries, let them run, check back when new episodes appear. 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 rarely gets discussed.
The math that surprises most people
Look at the logs on a typical Radarr instance and you'll find it scanning for new episodes every 12 hours. Sonarr does the same. On top of that, both run library cleanup tasks, missing-episode checks, and metadata syncs — all on independent schedules, all unaware of each other. The result: drives spinning up constantly throughout the day, even on a setup someone believes is already optimized.
A typical 3.5-inch hard drive uses about 5–7 watts when actively spinning, but the real cost is the spin-up spike. Every time a drive wakes from sleep, it draws 10–15 watts for a few seconds. Do that 50 times a day across multiple drives, and the electricity costs become real. Over a year, that's $150–300 depending on local rates and drive count.
The dollar amount may not seem dramatic in isolation. But it's entirely unnecessary.
Why this happens — and why it's hard to fix manually
Radarr and Sonarr are designed to be thorough. They want to ensure you never miss a new episode, keep your library clean, and check for updates. These are legitimate goals. Power efficiency for home hardware is not part of their design brief.
The deeper problem is that these tools don't communicate with each other. Radarr doesn't know that Sonarr is about to wake the drives in 10 minutes, so instead of batching tasks together, each tool does its own thing on its own schedule. Drives spin up, complete one task, spin down, then spin back up five minutes later for the next. It's the digital equivalent of every person in a house taking a separate trip to the kitchen instead of going together.
The built-in scheduling options compound this. You can set intervals, but you can't specify "run all maintenance tasks in a single one-hour window at 2 AM and leave the drives alone the rest of the time." You're working within whatever the developers decided makes sense by default.
What actually works
Audit your scheduled tasks first. Most people running these services don't actually know what's running or how often. Open the scheduled tasks view in both Radarr and Sonarr, write down what you find, and note the intervals. The number of active tasks and their frequency is usually a surprise.
Consolidate where you can. If Radarr is scanning every 12 hours and Sonarr is scanning every 12 hours, changing one to 24 hours costs almost nothing in practice. Most shows don't drop new episodes every 12 hours. The default frequency is overkill for the majority of setups.
Batch your tasks. This is the highest-leverage change. Instead of tasks scattered throughout the day, group them into a single maintenance window. Set Radarr to scan at 2:00 AM, Sonarr at 2:05 AM, cleanup tasks at 2:10 AM. Drives spin up once, complete everything, and go back to sleep. Instead of 50 wake-ups per day, you might have two or three.
Use sleep modes aggressively. If your server supports it, configure drives for aggressive sleep. Modern drives handle frequent sleep-wake cycles fine, and spin-up latency is negligible for these background tasks.
Monitor what's actually happening. Check system logs to confirm drives are actually spinning down between tasks. Some setups have a process that continuously pokes the drives, preventing sleep entirely. If that's your situation, finding and disabling that process matters more than any scheduling adjustment.
The honest limitations
This isn't a transformation — it's an optimization. These services still need to run, and power consumption won't drop to zero. If near-real-time episode availability is a hard requirement, aggressive batching into a single nightly window isn't the right tradeoff. And different hardware configurations create different constraints: a NAS with built-in power management gives you more leverage than a custom Linux box; cloud storage or remote libraries make some of this inapplicable entirely.
The point is to understand your specific situation and optimize for it, not to apply a generic configuration.
Why this matters beyond the electricity bill
The case for a homeserver is built around control — owning your data, understanding how your systems work, making deliberate choices instead of accepting defaults. Letting background tasks run wild without examination is a quiet contradiction of that principle.
There's also the wear factor. Every spin-up is a small amount of mechanical life taken off a drive. Reducing unnecessary wake-ups extends hardware lifespan — that's real value independent of the electricity cost.
The practical next step
Spend 15 minutes logging into your Radarr and Sonarr instances and reviewing the scheduled tasks view. Write down what's running and how often. Then ask whether those intervals reflect your actual needs, or whether they're just defaults you never revisited. For most setups, cutting task frequency in half produces no noticeable difference in functionality.
For more systematic batching, there's a lightweight daemon built specifically for this problem — it lets you define custom batching windows so maintenance tasks across both services run together rather than scattered through the day. It's available at https://arrpower.vercel.app. But even without a dedicated tool, a manual audit and some deliberate rescheduling will recover a meaningful amount of both electricity cost and drive lifespan.
Your homeserver doesn't have to be inefficient — it just requires the same attention you gave to setting it up.