I built an open-source tool for running ARG governance checks on a schedule and tracking findings

Most of the Azure governance work I have done over the last ten years ended the same way. Someone writes a sharp Resource Graph query, it finds something real, it gets pasted into a chat, and then it lives in that person's terminal history until they move on.

The failure that costs more is quieter. A check that stops running does not turn red. It stays green, and the estate keeps drifting behind a number that nobody has any reason to distrust.

Disclosure before I name anything: I built the tool below and I maintain it.

RuleBeat runs the governance checks your team writes for Azure on a schedule, tracks every finding over time, and never holds write access. A check is a rule you author against Azure Resource Graph or Microsoft Graph, in a visual builder or as raw KQL. It ships 158 checks out of the box, 15 built-in rules plus the 143-rule APRL pack. Findings keep their lifecycle across scans, so they move through new, active and fixed and reopen on their own, and a suppression needs a reason and can carry an expiry date.

The trade-offs, so nobody has to discover them after installing:

- Read-only, permanently. It never holds write credentials and never creates its own service principal. You create the credential, so you can see in Azure RBAC exactly what it was granted. The cost is real: there is no one-click fix. Remediation stays your action under your own identity.

- Self-hosted, one container, SQLite inside. Nothing about your tenant leaves your deployment and there is no telemetry. The cost is that you run it. Demo mode runs the real UI over a generated database with no Azure credential, if you would rather look before wiring anything up.

- Honest numbers. A rule that has never run, or whose last run failed, is reported as unknown rather than passing. The posture number is uglier for it, and that is the point.

On where this does and does not belong next to the native stack: Azure Policy is for enforcing a standard, and it does that better than anything I would write. Defender for Cloud covers its own scope well. If your assignments are enforcing, your Workbook answers the question you actually ask, and one person owns the whole loop, you do not need this. Where I kept running out of road was the organization-specific check that no built-in standard covers, and the question of who owns a flagged row once more than one person has to care about it.

It is open source under Apache-2.0 and free, and it is v0.2, early on purpose. I build it with AI assistance from Claude, which the public commit history shows in the co-author trailers, and every change is human-reviewed and gated by the test suite in CI before it ships.

Repo: https://github.com/rulebeat/rulebeat

Docs: https://docs.rulebeat.com

The question I would rather ask than answer: for those of you running recurring governance checks today, what do you do with a finding that is accepted on purpose? Every version of this I have seen was a tag, a wiki page, or a spreadsheet, and all three drift away from the query that produced them. I would like to know what has actually held up for you.