Events at a Glance

An optional layer sits on top of evaluation: register a database notification channel, or a function call, against a check, and the evaluation engine fires it automatically the moment that check's severity newly crosses into — or above — a floor you choose. This is entirely opt-in: a check with no events registered against it behaves exactly as it always has.

-- fire a notification on channel 'pghf_alerts' the moment PGHF11-009 (superuser count) first reaches warning
SELECT pghf.create_event('PGHF11-009', 'notify', 'warning', p_channel_name => 'pghf_alerts');

-- or call your own function instead, with whatever configuration it needs
SELECT pghf.create_event('PGHF11-009', 'function', 'critical',
    p_routine => 'my_schema.notify_pagerduty(bigint, jsonb)'::regprocedure,
    p_function_args => '{"service_key": "..."}'::jsonb
);

An event fires once per breach, not once per run: it fires the moment severity crosses into the floor you chose, then stays silent on every later run while the check stays at or above that level, firing again only after the check recovers and later breaches again. It's scoped to the same post-debounce severity the reporting functions show you, so it automatically respects whatever consecutive-failure requirement a check's threshold has configured (see How Threshold Evaluation Works). Events attach to a specific check, with no restriction on which namespace that check lives in — built-in or your own.

The full guide — every parameter, the exact firing rule with worked examples, the complete manage-and-troubleshoot lifecycle, and the permission model for who can register one — lives in its own dedicated book: Events.

Continue to Retention and Cleanup.