Alerts fire when a finding changes, not on every scan
RowShield is built around a simple discipline: an alert means something changed. Every scheduled scan compares its snapshot against the previous run, and only three kinds of difference leave the system as an alert — a finding being created, a finding regressing to an earlier broken state, and a finding being resolved.
This page explains what each transition means, why a project that stays broken stays quiet after the first page, and why a scan that runs twice cannot send two alerts.
The three transitions that produce an alert
Created means a rule matched for the first time in the recorded history of the project: a policy disappeared, a bucket turned public, a privileged key surfaced in a bundle. The alert arrives once, at the moment of discovery.
Regressed means a finding you had already resolved came back — the same rule matching again after a clean scan. Regressions get their own article because they usually say something about process rather than about the schema alone.
Resolved also produces an alert. Confirmation that a fix landed is worth a notification: it closes the loop without anyone having to re-run a scan by hand or watch the dashboard for the green state. Resolved events deliberately omit remediation SQL, because there is nothing left to apply.
Why a constant state pages nobody
A project sitting with RLS disabled does not need forty identical emails over a weekend; it needed one, at the moment it broke. Repeating the same alarm on every scan trains whoever receives it to stop reading, and an ignored channel protects nothing. So a finding that remains open from one scan to the next emits nothing at all.
Silence therefore carries information. If your destinations are quiet, every known problem is still exactly where it was — no better, no worse — and the dashboard always shows the full current list if you want the whole picture rather than the changes.
The same logic keeps the health score honest over time: it reflects the current state of the project, while the alert stream reflects the deltas between states. Neither has to shout to make the other audible. The discipline cuts both ways deliberately: confirmation of a resolution arrives once as well, so a channel going quiet after a fix means the fix held.
Retried scans emit nothing new
Scans run unattended, so retries happen: a worker restarts, a network blip interrupts delivery, a schedule overlaps. A retried scan is idempotent. The diff that produced a transition was recorded once, and re-running the comparison against the same previous snapshot finds the transition already recorded, so no second event exists to send.
The guarantee holds on the delivery side too: each dispatch outcome is written down before anything else happens, so a redelivered message is a retry of a recorded event rather than a fresh claim that something changed again.
Idempotence shows in the interface too: a retried run appears as the same scan completing rather than two runs disagreeing, and each alert refers to exactly one recorded transition.
Related questions
- A finding appeared between two scans while nobody was watching. Does the created alert still arrive?
- Yes. Transitions are detected by comparing snapshots, not by watching in real time, so the next scan reports the change as created whenever it runs — the alert is late, never missing.
- Can I receive a full report of everything currently open?
- The dashboard lists every open finding with its remediation SQL, and each alert names the affected table or bucket so you can jump straight there. Alerts are deliberately a stream of changes, not a periodic dump of state.
Did this answer your question? If not, tell us what is missing — article corrections go straight to the person who maintains it.