instance_up check writing two records to instance_up table - affects alert routing

[jasonhill-ds]

Describe the bug
instance_up check writes two records to the instance_up table when a configured source is down. If the source is up it only writes a row that matches the original source.

To Reproduce
Steps to reproduce the behavior:

1. Run pgwatch v5.2.0 (latest docker image)
2. Monitor a postgres database and ensure the instance_up check is running
3. Shutdown the monitored postgres database
4. Wait a couple of minutes and query the metrics database (select * from instance_up).
5. Note that there are rows for the source database that include details like the tags and there is a row for each check that just has the dbname.

Expected behavior
I would expect only a row as per pre-shutting down the monitored database. The issue is that grafana alerts that use the labels of the target database for routing end up not following the correct Notification Policies as there is a row that doesn't have the correct tags attached.

Screenshots
The monitored database from the pgwatch database:

Contents of pgwatch_metrics database instance_up table:

Desktop (please complete the following information):

• OS: Docker container based on cybertecpostgresql/pgwatch (v5.2.0)
• Browser N/A
• Version N/A

Additional context
pgwatch build info:
Version info:
Version: v5.2.0
Config Schema: 00824
Sink Schema: 01180
Git Commit: 8a90e89
Built: 2026-05-04T13:01:56+02:00

[pashagolub]

This is not a bug. You see 2 rows because they are written by 2 different sub-systems:

1. Rows with more details are written by reaper when it cannot execute the query, but it already has more information about the database because previously executions were OK.
2. Rows with epoch_ns and instance_up fields only are written by the sources discovery. That means pgwatch is trying to refresh sources configuration but listed database is not responding. It signals about it.

If you want to get rid of the second one, you may increase --refresh= value. By default, it's 120sec, which is exactly the interval you see here. Please, remember that increasing refresh rate will affect newly added monitored sources and metrics, and may lead to restart of pgwatch to apply changes.