Overriding a Threshold Per Suite

A check-level default applies everywhere that check runs; a per-suite override applies only when running that one specific suite — for example, a stricter production suite that's less tolerant than whatever the default suite uses for everyone else. The results-reporting function is the easiest way to see an override actually taking effect, since it's the same check and the same collected value under both suites — only the severity changes.

1. A deterministic demo check

A fixed value, so the override's effect doesn't depend on real server load:

CREATE OR REPLACE FUNCTION pghf.chk_demo_ratio(p_run_id uuid)
RETURNS pghf.check_result LANGUAGE sql AS
$$ SELECT ROW('COLLECTED', jsonb_build_object('value', 75), NULL)::pghf.check_result; $$;

SELECT pghf.upsert_namespace('X', 'My Company Checks');
SELECT pghf.upsert_category('X', '03', 'Threshold Override Demo');

SELECT pghf.create_check('X', '03', 1, 'fixed-75 demo check',
    'pghf.chk_demo_ratio(uuid)'::regprocedure, 'numeric',
    p_rationale => 'Demo check for showing threshold-override precedence — not a real monitoring signal.',
    p_numeric_direction => 'lower_is_better');
-- => 'X03-001'

2. A lenient check-level default, and a stricter override scoped to a dedicated suite

SELECT pghf.set_threshold('X03-001', p_warn_value => '80'::jsonb, p_crit_value => '90'::jsonb);

SELECT pghf.create_check_run('strict_prod', 'tighter thresholds for production');
SELECT pghf.add_check_to_run('default', 'X03-001');
SELECT pghf.add_check_to_run('strict_prod', 'X03-001');
SELECT pghf.set_threshold('X03-001',
    p_check_run_id => (SELECT check_run_id FROM pghf.check_runs WHERE run_key = 'strict_prod'),
    p_warn_value => '50'::jsonb, p_crit_value => '70'::jsonb);

Two threshold records now exist for X03-001 — one default, one override — and setting a threshold is exactly the same call for both; only whether you pass a specific suite decides which one you're writing.

3. Run and evaluate both suites, then compare

CALL pghf.execute_check_run(p_run_key => 'default', p_run_id => v_default_run);
CALL pghf.evaluate_run(v_default_run);
CALL pghf.execute_check_run(p_run_key => 'strict_prod', p_run_id => v_strict_run);
CALL pghf.evaluate_run(v_strict_run);

SELECT * FROM pghf.get_results_sql(v_default_run) WHERE check_id = 'X03-001';
--  severity | category_id | check_id |     check_name      | value | message
-- ----------+-------------+----------+---------------------+-------+---------
--  ok       | X03         | X03-001  | fixed-75 demo check | 75    |

SELECT * FROM pghf.get_results_sql(v_strict_run) WHERE check_id = 'X03-001';
--  severity | category_id | check_id |     check_name      | value |                message
-- ----------+-------------+----------+---------------------+-------+-----------------------------------------
--  critical | X03         | X03-001  | fixed-75 demo check | 75    | value 75 exceeds critical threshold 70

Same check, same collected value (75) both times — the reporting function makes the override's effect immediately visible: ok against the lenient default (75 is under 80), critical against the stricter suite's override (75 exceeds 70). The override lookup happens automatically inside the evaluation engine, and always prefers a matching suite-specific record over the default when both exist — which is what changed the outcome here, even though nothing about the check or its collected value did.

Continue to Percentage-of-a-Ceiling Checks.