Skip to content

Adding a Threshold

Collecting data and judging it are separate steps. Once your check is registered — built-in or custom, no distinction — give it a threshold:

SELECT pghf.set_threshold('X01-001',
    p_warn_value => '5'::jsonb,
    p_crit_value => '10'::jsonb);

This is the only function for setting thresholds — seeding a built-in check's default, adding one for your own check, registering a per-suite override, and later updating any of the above are all just calls to this same function. It's an upsert: calling it again for the same check and suite combination replaces the values in place. There's no protected "seeded" state — every one of the framework's own built-in default thresholds was written by calling this exact function, and you can override or update any of them the same way.

  • The soft, middle, and hard tiers — any combination may be set, matching your check's numeric direction. Direction is read from the check's own catalog record, not repeated here — a "lower is better" check breaches when the value exceeds a tier; "higher is better" breaches when it falls below one; "a specific target is the ideal" treats each tier as a maximum allowed distance from that ideal value.
  • The boolean-breach-severity parameter is for boolean-typed checks instead of numeric tiers: which severity a value that doesn't match the check's configured "pass" value maps to.
  • Leaving the suite parameter empty sets a check-level default (applies wherever the check runs); passing a specific suite's identifier sets an override that only applies to that one suite.
  • The consecutive-breaches parameter is debounce: require a chosen number of consecutive breaching runs before the breach counts as confirmed. The default is 1 (no debounce).

Evaluate a run once it's been collected:

CALL pghf.evaluate_run(p_run_id => '<run_id from execute_check_run>');
SELECT * FROM pghf.get_results_sql('<run_id from execute_check_run>');

The raw severity is what this one run's data says on its own; the confirmed severity is the raw severity after debounce has been applied. Use the confirmed severity for anything downstream — alerting, dashboards — the raw severity is mainly there so a debounce lookback (and you, while debugging) can see the un-smoothed signal underneath it.

Continue to Debounce: Requiring Consecutive Failures.