Staros Labs
·2 min read

Why I Forked Scrutiny

The Problem

Scrutiny is one of those tools that just works. You set it up, it monitors your drives, and it tells you before things go wrong. For anyone running a homelab or managing storage infrastructure, it's invaluable.

But open source projects have a lifecycle. The original Scrutiny repository started accumulating pull requests — good ones, from the community — that weren't being merged. Features people needed, bugs that needed fixing, all sitting in review limbo.

Taking Over

Rather than let those contributions die, I decided to fork the project and start merging them. The goal was simple: keep Scrutiny alive and moving forward while maintaining full backward compatibility.

What started as merging a few PRs turned into something bigger. The community had built some impressive features that deserved to be part of the main project.

What Changed

The fork now includes features that the community has been asking for:

  • ZFS pool monitoring for those of us running ZFS
  • Prometheus metrics so you can build Grafana dashboards
  • Home Assistant integration via MQTT
  • API authentication for security-conscious deployments
  • A complete Angular upgrade from v13 to v21

Each feature was contributed by someone who needed it, tested it, and submitted a PR. The fork just brings them all together.

Lessons Learned

Maintaining a fork is different from building something new. You have to respect the original architecture, keep backward compatibility, and make sure existing users can upgrade without breaking anything.

It's also taught me that open source isn't just about writing code — it's about stewardship. Sometimes the most valuable thing you can do is keep something working.

What's Next

The fork continues to accept contributions and merge improvements. If you're using Scrutiny, consider switching to the fork for the latest features and fixes.

Check out the project page for the full feature list and deployment instructions.