Alert Delivery Status Theater Automation: Logged as "Sent" to Nowhere

Recording a status like "sent", "delivered" or "completed" alongside an automated action is standard, useful practice — it turns a system's own behavior into a reviewable history. The entire value of that practice depends on the status genuinely describing what happened, checked at the moment it is recorded, rather than being written down as an assumption of what SHOULD happen once some other, not-yet-built piece of the system eventually exists. A status field set before its own underlying action is confirmed — or, in the extreme case, before that action even exists in code at all — is not a smaller, less certain version of a real status; it is a fabricated one, and it reads identically to a genuine one to anyone consulting the record later.

Centriu Atlas runs a scheduled job evaluating an organization's own configured monitoring rules — a metric crossing a threshold, for example — and recording a permanent event in `atlas_alert_events` whenever one fires, intended as the durable, reviewable history of what the alerting system has caught over time.

Before this fix, the exact moment a rule fired, the job built a subject line and a message body for the alert, and then inserted the `atlas_alert_events` row with `delivery_status` set to the literal string `"sent"` — written directly into the insert, with no check, no downstream call, and no dependency on anything actually happening first. The single line of code immediately preceding it, in a comment, read (translated) "Persist + (future) call atlas-notify-email" — the author's own contemporaneous note that the actual delivery mechanism, a call to a dedicated notification function, was explicitly deferred to a later point in time that, until this fix, had never arrived. The practical result: every single alert that fired, for the entire time this code was live, was recorded in the system's own permanent history as having been successfully sent — with genuinely zero mechanism in place capable of sending it anywhere at all. A team relying on that audit trail to confirm they had been notified about a real operational issue would find a record insisting they had been, regardless of whether that was ever true.

The fix replaces the assumption with a real action and a real, checked outcome. On a rule firing, the job now inserts a row into `atlas_notifications` — a table whose inserts are wired, via a database trigger (`trg_atlas_notify_email_on_notification`), to two real, observable effects: a genuine email is dispatched to the internal team through a dedicated notification edge function, and the alert becomes visible as an entry in the product's own Messages tab, reviewable by anyone with access to it. The outcome of that specific insert — whether it succeeded or returned an error — now DIRECTLY determines the `delivery_status` value recorded alongside the alert event: `"sent"` only when the notification insert genuinely succeeded, `"failed"` when it did not, with the underlying error message surfaced into the job's own error-reporting list rather than being silently discarded. A status field that used to be written before anything happened is now written strictly after, and strictly as a function of what actually did.

Before the fix, a monitoring rule crossing its configured threshold inside Centriu Atlas would produce a permanent audit-trail entry reading, in effect, "alert fired, delivery: sent" — regardless of the fact that the specific mechanism meant to deliver that alert to anyone was, per the surrounding code's own comment, still an unbuilt future step. A team reviewing that history weeks later, checking whether they had been notified about a specific incident, would find a record confidently confirming delivery that never actually occurred. After the fix, the same rule firing produces a real notification, a real email, and a `delivery_status` that reflects whether that specific attempt genuinely succeeded.

Centriu Atlas's internal alerting cron now performs a real notification action when a monitoring rule fires — triggering a genuine email and a visible entry in the product's own Messages tab — and records the alert event's `delivery_status` from that action's real, checked outcome, closing a gap where every fired alert was permanently logged as successfully delivered regardless of whether any delivery mechanism existed to send it.

This automation governs Centriu Atlas's own internal monitoring-rule alerting mechanism specifically — it does not change what rules can be configured or how a threshold is evaluated, and it is specific to the delivery-status field this fix corrected; other status fields elsewhere in the product were not found to share this defect and were not touched by this fix.

Writing a status field to reflect what a system INTENDS to do next, before that next step is even built, can feel like a harmless placeholder during active development — the field has the right shape, and nothing downstream is broken by it. The risk is specific to what happens if that placeholder is never revisited: it becomes a permanent, indistinguishable-from-real record of an action that never occurred. Writing the status only after checking the real outcome of a real action costs one extra conditional, and is the only version of the field capable of actually meaning what it claims.