Metric storage and retention

Where the data lives

Metrics and alerts are stored in the platform's own PostgreSQL database, in the schema monitoring. Metrics use the TimescaleDB extension: the module creates the extension, a hypertable for the raw readings and four roll-ups built from it when it starts.

Collection and checks

What	How often
Reading every source	Every 15 seconds, up to 32 sources at a time. A source that fails is retried after a growing pause of at most 2 minutes
Node capacity — allocatable and requested CPU and memory	Every 15 seconds
Running the alert rules	Every minute
Deleting resolved alerts past their retention	Every 6 hours

Metric retention

Table in monitoring	Holds	Kept for	Compressed after
metric_samples	Every reading as taken	7 days	2 days
metric_samples_1m	1-minute summaries: average, minimum, maximum, first and last	7 days	1 day
metric_samples_5m	5-minute summaries	30 days	7 days
metric_samples_1h	Hourly summaries	180 days	30 days
metric_samples_1d	Daily summaries	730 days	90 days

• Each roll-up is refreshed on the rhythm of its own width: the 1-minute one every minute, the daily one once a day.
• Data is dropped in whole blocks of time — one day for the raw table and the 1-minute roll-up, 7 days, 30 days and 90 days for the others — so a table can hold up to one block more than its retention.
• These periods are part of the module, not settings. Each time it starts, the module re-applies the block sizes and the refresh schedules, and adds a missing retention or compression policy. A statement it cannot apply is logged as Timescale policy statement did not apply and the module carries on.

Which table a query reads depends on the length of its range; what that means for users is in Resolution and history.

Alert retention

A resolved alert is deleted Alerts__RetentionDays days after it resolved — 30 by default. A value of 0 or less keeps every alert. An alert that is still firing is never deleted. The setting is described in Settings.

Check that retention runs

Retention, compression and the roll-ups run as database background jobs. The Database tab of the Health page lists every background job with how many of its runs succeeded, and puts a job that has run but never once succeeded at the top in red. A retention job that never succeeds lets the tables grow until the database's volume is full.