Firing a Notification on a Severity Change

Everything so far gets you a severity recorded against a run — reading it back out (through the reporting functions, or a scheduled poll) is still up to you. The notifications layer is the other option: register one against a check, and the evaluation engine fires it automatically, with no polling needed.

-- NOTIFY a channel the moment X01-001 first reaches warning or worse (on_change)
SELECT pghf.create_notification('x01 alerts', 'notify', p_check_id => 'X01-001',
    p_min_severity => 'warning', p_channel_name => 'x01_alerts');

-- or call your own function — signature (bigint, bigint, jsonb) RETURNS void,
-- with whatever config it needs passed through as p_function_args
SELECT pghf.create_notification('x01 slack', 'function', p_check_id => 'X01-001',
    p_severities    => ARRAY['critical'],
    p_routine       => 'my_schema.notify_slack(bigint, bigint, jsonb)'::regprocedure,
    p_function_args => '{"webhook_url": "https://hooks.example.com/..."}'::jsonb);

A notification needs a threshold or evaluator already in place — a check with neither always evaluates "not evaluable," which no notification watching a real-severity set fires on.

You make two choices (covered in full in the Notifications book): when it fires — on_change (once on a transition into your severity set, the default) or on_state (every evaluation in the set — one firing per occurrence, ideal for on-event checks, throttled by an optional cooldown) — and how it's delivered — outbox, notify (a standard PostgreSQL NOTIFY), pg_relay_notify (a pg_relay enqueue; needs pg_relay), or function, all landing in one durable outbox.

For the full picture — every parameter, the exact firing rule with worked examples, managing the lifecycle, wiring your own delivery, the optional pg_relay_notifier path, the permission model, and a troubleshooting checklist — see the dedicated Notifications book.

Continue to On-Event Checks.