The Catalog

At the end of installation, pg_health_framework populates its entire built-in catalog in one automatic call to pghf.seed_data(). Most sites never register a namespace, category, or check of their own — running and evaluating what's already there is the whole job. This book covers exactly what's in the box: the namespace, categories, checks, and suites the framework ships with, how to read and manage them, and where to go if you need your own.

If you just want to run the built-in checks, you can skip straight to Running Checks End to End in the User Guide — this book is the reference for the catalog's own structure, not a required prerequisite.

You can re-run the seeding function yourself at any time — it's perfectly safe, and it's how a future version of the framework delivers fixes and new checks (see Resetting to Defaults):

SELECT pghf.seed_data();
-- NOTICE:  pghf.seed_data(): namespace, 15 categories, 175 checks, 7 suites, 114 thresholds upserted.

What's seeded

• 1 namespace — PGHF, "PostgreSQL Health Framework."
• 15 categories underneath it — see the table below.
• 175 checks — one PostgreSQL function each, covering everything from basic reachability to Spock replication lag. See Metadata Columns Explained for what's recorded about each one.
• 7 suites — seeded-1m through seeded-on-demand, a partition of the whole built-in catalog by recommended run cadence (see Suites below). Every check belongs to exactly one, and the seeding function refuses to run if that ever stops being true — a new built-in check can't silently end up on no schedule at all. (One more suite exists beside these seven: event_alerts, the fixed, permanent run container for on-event checks — not part of this cadence partition, and querying pghf.check_runs directly shows 8 rows, not 7, for exactly that reason.)
• 114 default thresholds (7 of them via custom evaluators) — a core set carried over from pgEdge's own upstream pg-healthcheck project's tuned defaults (see the Licence book for attribution), extended with defaults for the rest of the judgeable catalog. The complete list — every check, its classification, and the exact rule it ships with — is in the Default Thresholds Reference.

Categories

Every check's ID is built from PGHF plus its category code plus a zero-padded run number — for example, PGHF01-006.

Category code	Category	Checks
01	Connection & Availability	6
02	pgBackRest Configuration & WAL Archiving	3
03	Performance Parameters	20
04	Long-Running Queries & Lock Contention	11
05	Vacuum & Autovacuum Health	16
06	Index Health	10
07	TOAST Table & Corruption Detection	9
08	Visibility Map Integrity	6
09	WAL & Replication Slot Health	16
10	pg_upgrade Readiness (opt-in)	15
11	Security Posture	12
12	pgEdge / Spock Cluster	25
13	OS & Resource-Level Checks	10
14	WAL Growth & Generation Rate	13
15	Replication Health	3

175 checks in total. ("WAL" is PostgreSQL's write-ahead log, its own internal record of every change made to the database — see the Glossary if you'd like the full explanation. "TOAST" is PostgreSQL's mechanism for storing very large field values out of line from the main table row.)

For what each individual check actually measures, why it matters, and how to fix a bad result — every one of the 175, organised by category — see the Check Reference.

Suites

The seven seeded suites partition all 175 built-in checks by recommended run cadence — every non-retired check sits in exactly one:

Suite	Checks	Cadence
seeded-1m	12	Every minute — the fast-moving liveness signals: active and blocked sessions, lock waits, WAL generation rate, replication lag.
seeded-5m	34	Every 5 minutes.
seeded-15m	20	Every 15 minutes.
seeded-1h	20	Hourly.
seeded-daily	64	Daily — configuration, capacity, and hygiene checks.
seeded-weekly	10	Weekly — the slow-moving audits.
seeded-on-demand	15	Run by hand when the occasion arises — today, exactly category 10 (pg_upgrade readiness), which needs a target PostgreSQL version to mean anything and is never on a schedule.

The names are a convention, not a mechanism — this framework still schedules nothing itself. The suites exist so your scheduler wiring is six one-liners (CALL pghf.run_and_evaluate('seeded-5m'); every 5 minutes, and so on) instead of a hand-built partition of 175 checks. Because evaluation history is one stream per check regardless of which suite ran it, Alert Status merges all the cadences into a single current-state view.

The Spock-cluster checks (category 12) sit in their cadence suites like everything else and cleanly report themselves as skipped on a server without Spock — there is deliberately no seeded "no-Spock" variant. If you want them structurally absent from the plan rather than merely skipping, build your own suite. Installing Spock is never required to use this framework.

Two things to know about seeded-suite membership: it's rebuilt authoritatively every time the seeding function runs — a re-seed resets any manual edits you made to a seeded-* suite, so put your own checks in your own suites, which a re-seed never touches — and it's guarded: a built-in check missing from every seeded suite, or present in two, makes the seeding function fail outright rather than quietly mis-partition.

This same cadence also drives two other seeded defaults: minimum report intervals (fast suites get a digest interval so a repeat finding isn't re-reported every single run) and hysteresis (every thresholded check outside seeded-on-demand requires 2 consecutive clean runs, within a window sized to 2x its own cadence, before clearing a confirmed breach — breach confirmation itself stays instant everywhere, so a fresh install's first run still shows real problems).

Both of those are calibrated to the cadence a suite's name implies — not to anything this framework actually does. There is no scheduler here (see Scheduling Health Checks), so nothing makes seeded-1m actually run once a minute; that's entirely up to whatever cron/orchestrator you point at it, if any. Run a built-in check from your own suite on your own schedule, purely by hand with no schedule at all, or skip these seeded suites and thresholds altogether and use only collection and evaluation against checks of your own — all fully supported, and none of it obligated to match the numbers above. If your real usage departs from a check's assigned cadence, retune (or clear) its report interval and hysteresis window yourself with pghf.set_report_interval()/pghf.set_threshold().

For a pg_upgrade-readiness pass, run seeded-on-demand (or a dedicated suite of your own) and pass a target PostgreSQL version:

CALL pghf.execute_check_run(p_run_key => 'seeded-on-demand', p_target_version => 17);

Continue to Metadata Columns Explained.