I announced DruScan a month ago on the project blog. It's been a few more weeks of fixing weird bugs, but this weekend I've finally been able to stop checking the error logs every time a new user signs up. I'm sharing it here too, on my personal blog, in case anyone working with Drupal still hasn't heard about it.
For anyone who hasn't come across it, it's two things that work together or separately: a free audit module contributed on Drupal.org, and a SaaS dashboard where you can see at a glance the health scores of all the projects where you install it.
For me, it's also a bet to stop having my freelance income depend 100% on the hours I sell to clients. If it works, I can start to scale without having to add more hours to the day.
Where This Came From
I told the long story here a while back. The short version is that I had years of scattered bash scripts for auditing Drupal projects, a conversation at DrupalCamp Spain in Santiago last September gave me the idea of beefing them up, and I started building it seriously in October.
The first version read the configuration exported to code from the project and ran directly against the repository, without needing to touch the site. I ended up dropping that approach. On one hand, not everyone gives you access to their repo if you want to set this up as a SaaS. On the other, what's in the repo doesn't always match what's running in production, because between deploys and overrides, things drift apart.
In the end I went the other way: a module installed on the site itself, with full access to configuration and database, running only read queries depending on what needs to be checked in each case. I tested it on two real client projects at the end of the year and, between what it detected well and what it detected poorly, I refined the severity classification. Things I was initially flagging as errors turned out to be intentional decisions for that specific project, so I moved them to notices. That part doesn't show up in the documentation, but it's what makes the difference between the tool being useful or burying you in false positives.
The dashboard came as a natural consequence. Once I had the module working well on real projects, the next question was how to see the state of multiple sites without logging into each one. That's where DruScan came from.
What It Actually Is
The audit module is published at drupal.org/project/audit. It's free and stays free. It runs more than 200 checks on any Drupal 10 or 11 project: performance, security, configuration, bad practices, pending updates, and more. It gives you a score from 0 to 100 for each category and classifies what it detects by severity: errors (things you need to fix right away), warnings (things worth looking at), and notices (informational alerts). If you only want to use the module and never send data anywhere external, you can do that without issue. The audit stays on your server.
DruScan is the dashboard the module sends scores to, if you decide to activate it with an API key. Only numbers between 0 and 100 per category get sent, plus the list of modules with their versions for the update alerts. No code, no content, no user data.
What It Solves for Me
My case is a bit unusual. Given the way I work, I move between several clients at the same time and, depending on the month, I can be doing very different things in each one.
Roughly, I move between three roles. On some projects I come in as an external auditor: a website lands on my desk with a vague complaint along the lines of "this is slow" or "this isn't quite working right", often the client doesn't even know what the real problem is, so I have to dig in and provide a diagnosis. On others I come in as a freelance developer, doing backend or frontend for agencies that need extra hands, and in some of those cases I also end up acting as a technical second opinion or as a project manager overseeing what the agency does. And then there are the projects where my role is just maintenance and updates, making sure nothing breaks.
I'm not an employee who gets told "do this" and does it. I almost always have to share my technical opinion and justify why something should be done one way or another. And, in many cases, follow up over weeks or months to see how the project evolves: whether code quality improves, whether the things I had documented have been fixed, whether what's in development has a better score than what's in production.
For all of that, DruScan changes my day-to-day.
Before, to know how any client project was actually doing, I had to manually log into the admin of each one, look in several places, and connect the dots. Now I open the dashboard and see at a glance which projects need attention this week, whether that's performance, security, bad practices, or pending core or contrib updates.
And since you can connect multiple environments to the same project (development, staging, production), if there's a regression in staging compared to production, the alert fires before the deploy reaches the client. On projects where I'm following up over months, that lets me show the client with actual numbers that what's being deployed to production is better than what was there before, not just tell them.
If you manage a single site, the free module is enough. If you handle several projects at the same time, especially with different roles depending on the project, the dashboard changes your day-to-day quite a bit.
And Why Now and Not a Month Ago
In April, when I published the stable version on Drupal.org and opened registration on DruScan, I wrote about it on the project blog but didn't make much noise elsewhere. The reason is the usual one: it was running in my own environment, on my own projects, and even though it worked fine, there was always some weird bug showing up in some scenario I hadn't considered. The last few weeks have been almost all support and infrastructure, fixing cases that only show up on hosting setups and configurations I don't have at hand.
Today it's at a point where I can show it without waiting for the "hey, this crashed on X". They'll keep happening. But not at the rate they used to. That's why now I'm finally up for sharing it here too.
How to Try It and What I'm Asking in Return
If you work with Drupal and want to give it a try, install the module from drupal.org/project/audit and, if you want the dashboard, sign up for free at druscan.com. The free plan doesn't ask for a card and works for unlimited projects.
What I'm asking for is honest feedback. If you find it useful, tell me. If not, tell me too. If you miss something specific (a metric that doesn't show up, an integration that's not there, an alert that falls short), write to me. I'm at the point where what you tell me now has a real impact on what gets built next.
And if you know anyone managing several Drupal projects who could use this, passing the word along is appreciated.