Anatomy of a RowShield drift alert

The identity block

Every alert opens by naming its subject precisely: object kind (table, policy, bucket, function), fully qualified name, and owning project. Ambiguity is the enemy of night-time triage, so names arrive resolved from catalog identity rather than inferred from logs — the actual pg_policies row for policy changes, the actual bucket id for storage changes.

The transition label rides beside the identity: created, resolved, or regressed. That word frames everything downstream — created asks whether this should exist, resolved confirms a fix landed, regressed demands a process conversation. Three investigations with three different owners, sorted by one field.

The evidence block

Next comes the delta itself. Where drifted state intersects a shipped rule, the alert annotates the mapping — a policy drifting to constant true arrives carrying the tautology finding and its severity, so classification happens once centrally instead of in every reader’s head. Purely structural moves stay informational, because not every change deserves alarm.

Before-and-after context travels inline: prior snapshot state beside current, so nobody reconstructs history from memory mid-incident. The design goal is that every alert is answerable with act, acknowledge, or ignore — and a stream that routinely defeats that test indicates the alert content, not the reader, needs fixing.

The action block

When remediation applies, generated SQL rides inside the alert — built from live columns, FORCE ROW LEVEL SECURITY included, copy-ready — alongside a deep link to the finding in the dashboard. Delivery follows configured destinations and their thresholds: Slack Block Kit or Discord embeds for chat, HTML email for the record, generic webhooks for ticketing routes.

All channels render from one event, so payload and Slack message agree by construction. Boring consistency, chosen deliberately.

Reading one end to end

A worked example makes the shape concrete. A generated migration recreates the orders table between two scans; the next cycle emits a created transition for the table plus created findings for missing posture, each carrying severity and remediation SQL built from live columns. Paste the enable-force-policy block, re-run the probe, and the following cycle closes the loop with resolved transitions — no human compiled the inventory or adjudicated the diff.

Now the regressed case: a bucket flipped public returns after someone reverts a hotfix branch. The alert names the regression explicitly and links the original resolution from finding history, letting you fix the revert instead of rediscovering the problem. That historical thread — when it was fixed, what broke since — separates an alert stream from an audit trail.

Frequently asked

When exactly do drift alerts fire?

On transitions only — created, resolved, or regressed. Unchanged state never notifies, retried scans emit nothing, and a project sitting broken pages exactly once.

Do alerts include row data?

Never. Findings report column names and counts; exposed keys appear as fingerprints; webhook URLs arrive masked. Content is designed safe to paste anywhere, including group chats.

Can severities route differently per channel?

Yes — each destination carries its own threshold, so chat interrupts for critical drift while email quietly archives informational movement.

What if an alert is wrong?

Challenge it via the support address on the article footer. Misclassified transitions are treated as product bugs, not noise to tune around — the suppression philosophy applies to alerts too.