starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

Monitor Postgres query result #1575

New issue

Closed

opened 2026-02-28 02:25:57 -05:00 by deekerman · 14 comments

deekerman commented

2026-02-28 02:25:57 -05:00

Owner

Originally created by @thedatabaseme on GitHub (Nov 23, 2022).

⚠️ Please verify that this feature request has NOT been suggested before.

I checked and didn't find similar feature request

🏷️ Feature Request Type

New Monitor

🔖 Feature description

I would love to see the possibility within Uptime-Kuma, to specify an expected result within a SQL query monitor type (e.g. Postgres).
So a SQL monitor would not only check if it can connect to a database and can execute a query.
Another wish from my side would be, to store the query result in the heartbeat data. You could cut the result to save space, but at least one would have some idea on how the result looked like.

✔️ Solution

I want to check for the replication status of a Postgres cluster and if a specific cluster member is in recovery or not. So a query like select * from pg_is_in_recovery(); would return either t (true) or f (false). I would like to have the possibility to monitor for the expected result.

❓ Alternatives

If you don't consider to implement this request, at least the result should be exported as a metric so that I can filter on it later. Implementing both options, would be the best solution.

📝 Additional Context

No response

Originally created by @thedatabaseme on GitHub (Nov 23, 2022). ### ⚠️ Please verify that this feature request has NOT been suggested before. - [X] I checked and didn't find similar feature request ### 🏷️ Feature Request Type New Monitor ### 🔖 Feature description I would love to see the possibility within Uptime-Kuma, to specify an expected result within a SQL query monitor type (e.g. Postgres). So a SQL monitor would not only check if it can connect to a database and can execute a query. Another wish from my side would be, to store the query result in the heartbeat data. You could cut the result to save space, but at least one would have some idea on how the result looked like. ### ✔️ Solution I want to check for the replication status of a Postgres cluster and if a specific cluster member is in recovery or not. So a query like `select * from pg_is_in_recovery();` would return either `t` (true) or `f` (false). I would like to have the possibility to monitor for the expected result. ### ❓ Alternatives If you don't consider to implement this request, at least the result should be exported as a metric so that I can filter on it later. Implementing both options, would be the best solution. ### 📝 Additional Context _No response_

deekerman

2026-02-28 02:25:57 -05:00

closed this issue
added the
feature-request

A:monitor

good first issue
labels

deekerman commented

2026-02-28 02:26:01 -05:00

Author

Owner

@blackandred commented on GitHub (Dec 1, 2022):

Alternatively you can try to use Infracheck with a custom script, expose the endpoint and just ping it using a regular HTTP check in Uptime Kuma.

https://infracheck.docs.riotkit.org/en/latest/

@blackandred commented on GitHub (Dec 1, 2022): Alternatively you can try to use Infracheck with a custom script, expose the endpoint and just ping it using a regular HTTP check in Uptime Kuma. https://infracheck.docs.riotkit.org/en/latest/

deekerman commented

2026-02-28 02:26:02 -05:00

Author

Owner

@cfoellmann commented on GitHub (Mar 20, 2023):

I am with @thedatabaseme
I would like to set my SQL statement and define a return value for up (and down).
Or just "0 = down" and "1 = up". Forming the return in your query is easy enough, right?

In my case I would count the rows of a table and return "DOWN" if the count is 0.

@cfoellmann commented on GitHub (Mar 20, 2023): I am with @thedatabaseme I would like to set my SQL statement and define a return value for up (and down). Or just "0 = down" and "1 = up". Forming the return in your query is easy enough, right? In my case I would count the rows of a table and return "DOWN" if the count is 0.

deekerman commented

2026-02-28 02:26:02 -05:00

Author

Owner

@grzywek commented on GitHub (Apr 11, 2023):

Totally for it. Doesn't seem to be very complicated to implement.

@grzywek commented on GitHub (Apr 11, 2023): Totally for it. Doesn't seem to be very complicated to implement.

deekerman commented

2026-02-28 02:26:02 -05:00

Author

Owner

@rogerioadris commented on GitHub (Apr 11, 2023):

Is there any condition of the query to return down? or is the query just executed without monitoring the return?

@rogerioadris commented on GitHub (Apr 11, 2023): Is there any condition of the query to return down? or is the query just executed without monitoring the return?

deekerman commented

2026-02-28 02:26:02 -05:00

Author

Owner

@thedatabaseme commented on GitHub (Apr 11, 2023):

Is there any condition of the query to return down? or is the query just executed without monitoring the return?

My understanding of the current implementation is, that there is no actual check for the result of the SQL query. When the query finishes without error, the monitor is up. Else it's down.

@thedatabaseme commented on GitHub (Apr 11, 2023): > Is there any condition of the query to return down? or is the query just executed without monitoring the return? My understanding of the current implementation is, that there is no actual check for the result of the SQL query. When the query finishes without error, the monitor is up. Else it's down.

deekerman commented

2026-02-28 02:26:02 -05:00

Author

Owner

@rogerioadris commented on GitHub (Apr 11, 2023):

Thanks for the answer.
I solved my problem as follows

IF NOT EXISTS(.........) BEGIN
    THROW 51000, 'ERROR XXXXX.', 1;  
END

@rogerioadris commented on GitHub (Apr 11, 2023): Thanks for the answer. I solved my problem as follows ```SQL IF NOT EXISTS(.........) BEGIN THROW 51000, 'ERROR XXXXX.', 1; END ```

deekerman commented

2026-02-28 02:26:02 -05:00

Author

Owner

@wvolkov commented on GitHub (Mar 20, 2024):

Thx to @rogerioadris idea, I could use it at PostgresSQL as well:

do
$$
declare
	total_errors int2;
	err_text text;
begin

select
		count(*) as total_errors,
		string_agg(p.query || ':\n' || p.context , '\n\n') as x 
into
		total_errors,
		err_text
from
		pglog p
where
		error_severity != 'LOG'
		and application_name = 'pg_cron'
		and log_time > now() - interval '1 day';
	
IF total_errors > 0 THEN
    raise 'Failed Queries\n ```%s```', err_text;  
end if;
	
end
$$

@wvolkov commented on GitHub (Mar 20, 2024): Thx to @rogerioadris idea, I could use it at PostgresSQL as well: ```sql do $$ declare total_errors int2; err_text text; begin select count(*) as total_errors, string_agg(p.query || ':\n' || p.context , '\n\n') as x into total_errors, err_text from pglog p where error_severity != 'LOG' and application_name = 'pg_cron' and log_time > now() - interval '1 day'; IF total_errors > 0 THEN raise 'Failed Queries\n ```%s```', err_text; end if; end $$ ```

deekerman commented

2026-02-28 02:26:02 -05:00

Author

Owner

@YuriyGavrilov commented on GitHub (Sep 18, 2024):

What about Trino sql support? can I configure it already or need to support it?

@YuriyGavrilov commented on GitHub (Sep 18, 2024): +1 What about Trino sql support? can I configure it already or need to support it?

deekerman commented

2026-02-28 02:26:02 -05:00

Author

Owner

@YuriyGavrilov commented on GitHub (Sep 18, 2024):

Maybe add support sqlalchemy instead of adding db one by one?
Trino does not supported yet (((

@YuriyGavrilov commented on GitHub (Sep 18, 2024): Maybe add support sqlalchemy instead of adding db one by one? Trino does not supported yet (((

deekerman commented

2026-02-28 02:26:02 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Sep 24, 2024):

Maybe add support sqlalchemy instead of adding db one by one?

sqlalchemy is a python tool, while uptime kuma is written in js

Adding and maintaining monitors for every db out there is indeed unmanagable. I'd prefer to limit ourselves to the popular ones. Since I have not heard of Trino, I don't think this is a good fit.

You can always use the push monitor to push results to UK. This way, arbitrary checks can be performed, including databases without the large support of postgres/..

@CommanderStorm commented on GitHub (Sep 24, 2024): > Maybe add support sqlalchemy instead of adding db one by one? sqlalchemy is a python tool, while uptime kuma is written in js Adding and maintaining monitors for every db out there is indeed unmanagable. I'd prefer to limit ourselves to the popular ones. Since I have not heard of Trino, I don't think this is a good fit. You can always use the `push` monitor to push results to UK. This way, arbitrary checks can be performed, including databases without the large support of postgres/..

deekerman commented

2026-02-28 02:26:02 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Nov 6, 2025):

The way we should go about this is to first migrate the pg monitor ot the new structure here:

https://github.com/louislam/uptime-kuma/tree/master/server/monitor-types

After this, adding conditions is very simple (see the dns monitor for details)

@CommanderStorm commented on GitHub (Nov 6, 2025): The way we should go about this is to first migrate the pg monitor ot the new structure here: https://github.com/louislam/uptime-kuma/tree/master/server/monitor-types After this, adding conditions is very simple (see the dns monitor for details)

deekerman commented

2026-02-28 02:26:02 -05:00

Author

Owner

@daltonpearson commented on GitHub (Dec 2, 2025):

The way we should go about this is to first migrate the pg monitor ot the new structure here:

https://github.com/louislam/uptime-kuma/tree/master/server/monitor-types

After this, adding conditions is very simple (see the dns monitor for details)

I've submitted a PR that migrates the pg monitor to the new structure.

@daltonpearson commented on GitHub (Dec 2, 2025): > The way we should go about this is to first migrate the pg monitor ot the new structure here: > > https://github.com/louislam/uptime-kuma/tree/master/server/monitor-types > > After this, adding conditions is very simple (see the dns monitor for details) I've submitted a [PR](https://github.com/louislam/uptime-kuma/pull/6443) that migrates the pg monitor to the new structure.

deekerman commented

2026-02-28 02:26:02 -05:00

Author

Owner

@ramonsmits commented on GitHub (Jan 6, 2026):

Just having a check that checks for number of rows in the result set to be either empty or non empty.

I have some queries where I expect rows and other monitoring queries that should NOT return rows.

FYI: THis is my solution for Postgres:

DO $$
BEGIN
    IF NOT EXISTS(
        SELECT 1 FROM public.message
        WHERE timestamp >= NOW() - INTERVAL '6 minutes'
    ) THEN
        RAISE EXCEPTION 'No messages found in last 6 minutes';
    END IF;
END $$;

This is similar to the TSQL solution mentioned earlier:

https://github.com/louislam/uptime-kuma/issues/2342#issuecomment-1503492239

@ramonsmits commented on GitHub (Jan 6, 2026): Just having a check that checks for number of rows in the result set to be either empty or non empty. I have some queries where I expect rows and other monitoring queries that should NOT return rows. FYI: THis is my solution for Postgres: ```sql DO $$ BEGIN IF NOT EXISTS( SELECT 1 FROM public.message WHERE timestamp >= NOW() - INTERVAL '6 minutes' ) THEN RAISE EXCEPTION 'No messages found in last 6 minutes'; END IF; END $$; ``` This is similar to the TSQL solution mentioned earlier: - https://github.com/louislam/uptime-kuma/issues/2342#issuecomment-1503492239

deekerman commented

2026-02-28 02:26:02 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jan 6, 2026):

The step from having its own monitor type and supporting conditions properly is not that large.
It is a 3-5 line change as you can see here

https://github.com/louislam/uptime-kuma/pull/6601

I think it is much simpler and does not require any true work. All work has been done, feature just needs to be enabled basically

@CommanderStorm commented on GitHub (Jan 6, 2026): The step from having its own monitor type and supporting conditions properly is not that large. It is a 3-5 line change as you can see here - https://github.com/louislam/uptime-kuma/pull/6601 I think it is much simpler and does not require any true work. All work has been done, feature just needs to be enabled basically

deekerman referenced this issue

2026-02-28 03:02:13 -05:00

Create multiple users and AD\LDAP authorization #2648