Files
supabase/apps/docs/content/troubleshooting/pgcron-debugging-guide-n1KTaz.mdx
T
e0280cb650 docs: restructure observability navigation and overview (#49505)
<!-- CURSOR_AGENT_PR_BODY_BEGIN -->
## Stack

Draft stack extracted from `docs/monitoring`. Merge bottom-up. The
troubleshooting *catalog* rewrite (`content/troubleshooting` and the
Diagnosing UI) stays out of scope.

1. #49503 move inspect and advisors
2. #49501 split Studio logs from ClickHouse queries
3. #49500 treat reports as signal dashboards
4. #49502 add Observe the data hub
5. #49506 add agent setup components
6. #49504 add hire-an-agent templates
7. **#49505** restructure observability nav, overview, Detecting, and
flatten Observe the data ← **this PR**

## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.

YES

## What kind of change does this PR introduce?

Docs update. Top layer in the observability stack.

## What is the current behavior?

The section is still titled Monitoring and Debugging, with a Debugging /
Monitoring split that does not match the new pages. The debugging guide
is still the master layer-isolation + symptom table. Observe the data is
split into “what data” vs “where to observe it,” which duplicates the
source pages.

## What is the new behavior?

- Section title is Observability
- Overview groups Observe the data, Detect and resolve, Hire an agent,
and Export
- **Observe the data is flattened by source.** Logs, Metrics API,
Database, Advisors, and Reports each list where to read that source.
There is no separate MCP/API/CLI/Studio nav group.
- **Observe vs Detecting:** Observe is the catalog (what exists, how to
access it). Detecting is how to *use* those sources to pick up a Health
/ Security / Performance / Usage signal. Named errors skip to
Diagnosing.
- Studio Logs sits under Logs. Reports sits beside the other sources.
- Troubleshooting stays in the global menu and also appears as
Diagnosing under Detect and resolve

## Additional context

This is the last PR in the stack. Together the seven PRs reconstruct the
`docs/monitoring` observability IA and guide content, without shipping
the troubleshooting catalog overhaul.
<!-- CURSOR_AGENT_PR_BODY_END -->

<div><a
href="https://cursor.com/agents/bc-a3cb5ece-925b-4046-b58a-5d69e9a9d794?cursor_ref=pr_footer&cursor_cta=open_in_web"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://cursor.com/assets/images/open-in-web-dark.png"><source
media="(prefers-color-scheme: light)"
srcset="https://cursor.com/assets/images/open-in-web-light.png"><img
alt="Open in Web" width="114" height="28"
src="https://cursor.com/assets/images/open-in-web-dark.png"></picture></a>&nbsp;<a
href="https://cursor.com/background-agent?bcId=bc-a3cb5ece-925b-4046-b58a-5d69e9a9d794&cursor_ref=pr_footer&cursor_cta=open_in_cursor"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://cursor.com/assets/images/open-in-cursor-dark.png"><source
media="(prefers-color-scheme: light)"
srcset="https://cursor.com/assets/images/open-in-cursor-light.png"><img
alt="Open in Cursor" width="131" height="28"
src="https://cursor.com/assets/images/open-in-cursor-dark.png"></picture></a>&nbsp;</div>

---------

Co-authored-by: Cursor Agent <cursoragent@cursor.com>
Co-authored-by: Saxon Fletcher <SaxonF@users.noreply.github.com>
Co-authored-by: Nik Richers <nik@validmind.ai>
2026-09-04 13:38:39 +10:00

198 lines
7.0 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
title = "pg_cron debugging guide"
github_url = "https://github.com/orgs/supabase/discussions/30168"
date_created = "2024-10-29T15:12:11+00:00"
topics = [ "database" ]
keywords = [ "pg_cron", "cron", "jobs", "scheduler", "debugging" ]
database_id = "9a55c946-877f-46ae-8b57-51934e02a36c"
---
This is a general guide for debugging pg_cron. Below lists issues and how to debug them
## Cannot create/edit/delete cron jobs
Cron jobs can only be modified with the respective SQL functions:
- Schedule: [cron.schedule](/docs/guides/database/extensions/pg_cron#delete-data-every-week)
- Alter: [cron.alter_job](/docs/guides/database/extensions/pg_cron#edit-a-job)
- Delete: [cron.unschedule](/docs/guides/database/extensions/pg_cron#unschedule-a-job)
If you are trying to make changes, use the cron functions. If the cron functions are inaccessible, contact [Support](/dashboard/support/new)
<br />
---
## Cron Jobs are not running
> You should consider initiating a software upgrade in the [General Settings](/dashboard/project/_/settings/general) if your Postgres version is below v15.6.1.122. Upgrading will give you access to pg_cron v1.6.4+, which has many bug fixes and auto-revive capabilities.
### Debugging steps:
#### Check to see if `pg_cron scheduler` is active
pg_cron operates as the `pg_cron scheduler` process within Postgres. Use the below query to check if the worker is active
```sql
SELECT
pid as process_id,
usename as database_user,
application_name,
backend_start as when_process_began,
wait_event_type,
state,
query,
backend_type
FROM pg_stat_activity where application_name ilike 'pg_cron scheduler';
```
If the query does not return a row, the worker has died. To revive it, you must go to the [General Settings](/dashboard/project/_/settings/general) and initiate a fast reboot:
<img
width="719"
alt="Screenshot 2024-10-29 at 12 27 24 AM"
src="https://github.com/user-attachments/assets/d7a2956c-08e0-4ebc-be08-d14a2383f36b"
/>
<br />
#### Check the `cron.job_run_details` table for more information
pg_cron creates logs in its own table `cron.job_run_details`. The below query checks for issues from the past 5 days :
```sql
SELECT *
FROM cron.job_run_details
WHERE
(status <> 'succeeded' AND status <> 'running')
AND
start_time > NOW() - INTERVAL '5 days'
ORDER BY start_time DESC
LIMIT 10;
```
Respond to the errors exposed appropriately.
> Long running jobs may show timeout errors. For jobs that are intended to execute for extended periods, consider wrapping their queries in functions with custom timeouts ([guide](/docs/guides/database/postgres/timeouts#function-level)).
<br />
#### Check if there are too many cron jobs running concurrently
pg_cron supports up to 32 concurrent jobs, each using a database connection. If too many jobs are running simultaneously, space them out to prevent connection overload and job failure.
The below queries shows all pg_cron jobs:
```sql
-- All jobs
select schedule, jobname, command from cron.job;
-- Count jobs
select COUNT(*) from cron.job;
```
The below query can be used to find actively querying jobs:
```sql
SELECT
pid as process_id,
usename as database_user,
application_name,
backend_start as when_process_began,
wait_event_type,
state,
query,
backend_type
FROM pg_stat_activity where application_name ilike 'pg_cron';
```
You can view your concurrent peak connection usage throughout the day at the bottom of the [Observability Dashboard](/dashboard/project/_/observability/database)
<br />
#### Check for database strain
Unfortunately, excessive resource strain can slow down or disrupt jobs.
Go to the [reports page](/dashboard/project/_/observability/database) (or [Supabase Grafana](/docs/guides/observability/metrics/grafana-self-hosted) if you have it setup), and check for signs of resource exhaustion. If it's clear your database is under pressure, consider upgrading your compute add-on or following the advice from one of the optimization guides:
- [Connections](https://github.com/orgs/supabase/discussions/27141)
- [Disk/IO](https://github.com/orgs/supabase/discussions/27003)
- [Memory](https://github.com/orgs/supabase/discussions/27021)
- [CPU](https://github.com/orgs/supabase/discussions/27022)
It is important to make sure you are running the latest release of pg_cron (1.6.4) if you're noticing strain. It is the most robust.
<br />
#### Check the logs for more information
Although `pg_cron` records errors in the `cron.job_run_details` table, in rare cases, more information can be found in the general Postgres logs. You can check the [SQL Editor](/dashboard/project/_/sql/new?skip=true&source=logs), with the query source set to **Logs**, for failure events with the following query
```sql
select
timestamp,
event_message,
log_attributes['parsed.error_severity'] as error_severity,
log_attributes['parsed.user_name'] as user_name,
log_attributes['parsed.query'] as query,
log_attributes['parsed.detail'] as detail,
log_attributes['parsed.hint'] as hint,
log_attributes['parsed.sql_state_code'] as sql_state_code,
log_attributes['parsed.backend_type'] as backend_type,
log_attributes['parsed.application_name'] as application_name
from logs
where
source = 'postgres_logs'
and log_attributes['parsed.error_severity'] in ('ERROR', 'FATAL', 'PANIC')
and match(log_attributes['parsed.application_name'], 'pg_cron')
order by timestamp desc
limit 100;
```
If you're interested in modifying the query, there is an advanced [guide](https://github.com/orgs/supabase/discussions/26224) for navigating the Postgres logs and a general-purpose [one](/docs/guides/observability/advanced-log-filtering) for applying filters.
<br />
#### Create custom logs within cron jobs
If it's still not clear what is occurring you may be able to capture more logs by running the pg_cron query inside a database function:
```sql
create or replace function log_example()
returns void
language plpgsql
as $$
begin
-- Logging start of function
raise log 'logging start of cron function call: (%)', (select now());
-- INSERT LOGIC HERE
-- Logging end of function
raise log 'logging end of cron function call: (%)', (select now());
exception
-- Handle exceptions here if needed
when others then
raise exception 'An error occurred in cron function <insert name here>. ERROR MESSAGE: %', sqlerrm;
end;
$$;
```
You can then search for your custom messages in the [Logs Interface](/dashboard/project/_/logs/postgres-logs)
<br />
#### Upgrading pg_cron version
The current version of `pg_cron` on Supabase is 1.6.4. It comes with a [few bug fixes](https://github.com/citusdata/pg_cron/releases/tag/v1.6.4). You should consider upgrading to Postgres v15.6.1.122+ in the [General Settings](/dashboard/project/_/settings/general) to get the latest extension.
<br />
#### Contacting support and the maintainers
Although Supabase includes the extension, it is maintained by Citus (a Microsoft subsidiary). You can contact Support for more help, but you should also consider creating an issue in the [pg_cron repo](https://github.com/citusdata/pg_cron).