mirror of
https://github.com/supabase/supabase.git
synced 2026-10-06 09:55:06 +03:00
<!-- 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> <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> </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>
80 lines
3.8 KiB
Plaintext
80 lines
3.8 KiB
Plaintext
---
|
|
id: 'postgres-connection-logging'
|
|
title: 'Postgres connection logging'
|
|
description: 'Enable or disable Postgres connection logging for audit and compliance.'
|
|
---
|
|
|
|
For security monitoring and compliance audits, Postgres can log connection lifecycle events to your project's [Postgres logs](/docs/guides/observability/logs#postgres), including events such as `connection received`, `connection authenticated`, and `connection authorized`.
|
|
|
|
## Default behavior
|
|
|
|
By default, Supabase sets `log_connections` to off for new projects and you must enable it first. This behavior matches common managed Postgres defaults and reduces log volume from high-frequency connection events.
|
|
|
|
Existing projects may retain different settings depending on plan and compliance configuration:
|
|
|
|
- **Team, Enterprise, and HIPAA organizations** — Connection logging is typically enabled to support audit requirements.
|
|
- **HIPAA projects** — Supabase enables connection logging when a project is marked as high compliance. The [Security Advisor](/dashboard/project/_/advisors/security) warns if connection logging is later disabled.
|
|
|
|
## Compliance considerations
|
|
|
|
<Admonition type="note">
|
|
|
|
If you need connection audit evidence for SOC 2 or other compliance programs, you must enable it explicitly.
|
|
|
|
</Admonition>
|
|
|
|
Connection logging supports audit and monitoring controls required by some compliance programs:
|
|
|
|
- **HIPAA** — High-compliance projects should keep connection logging enabled. See the [shared responsibility model for healthcare data](/docs/guides/deployment/shared-responsibility-model#managing-healthcare-data) and [HIPAA compliance guide](/docs/guides/security/hipaa-compliance).
|
|
- **SOC 2** — Users who need connection audit evidence should enable logging and retain logs according to their own policies. See the [SOC 2 compliance guide](/docs/guides/security/soc-2-compliance).
|
|
|
|
Disabling connection logging does not affect other Supabase logging (for example, [Platform Audit Logs](/docs/guides/security/platform-audit-logs), [Auth Audit Logs](/docs/guides/auth/audit-logs), or [pgAudit](/docs/guides/observability/advanced-log-filtering#configuring-pgauditlog)).
|
|
|
|
## Manage connection logging via the dashboard
|
|
|
|
You can configure connection logging from the **Log connections** setting in the [Database Settings](/dashboard/project/_/database/settings) section of the Dashboard.
|
|
|
|
Ensure that you have [Owner or Admin permissions](/docs/guides/platform/access-control#manage-team-members) for the project.
|
|
|
|
<Admonition type="note">
|
|
|
|
Connection events appear in [Postgres logs](/docs/guides/observability/logs#postgres). They are included by default when the Postgres log type is selected. Clear **Connection logs** under Postgres to hide them.
|
|
|
|
</Admonition>
|
|
|
|
## Manage connection logging via the Management API
|
|
|
|
You can also manage connection logging using the [Management API](/docs/reference/api/v1-update-postgres-config):
|
|
|
|
```bash
|
|
# Get your access token from https://supabase.com/dashboard/account/tokens
|
|
export SUPABASE_ACCESS_TOKEN="your-access-token"
|
|
export PROJECT_REF="your-project-ref"
|
|
|
|
# Get current Postgres config
|
|
curl -X GET "https://api.supabase.com/v1/projects/$PROJECT_REF/config/database/postgres" \
|
|
-H "Authorization: Bearer $SUPABASE_ACCESS_TOKEN"
|
|
|
|
# Enable connection logging
|
|
curl -X PUT "https://api.supabase.com/v1/projects/$PROJECT_REF/config/database/postgres" \
|
|
-H "Authorization: Bearer $SUPABASE_ACCESS_TOKEN" \
|
|
-H "Content-Type: application/json" \
|
|
-d '{
|
|
"log_connections": true
|
|
}'
|
|
|
|
# Disable connection logging
|
|
curl -X PUT "https://api.supabase.com/v1/projects/$PROJECT_REF/config/database/postgres" \
|
|
-H "Authorization: Bearer $SUPABASE_ACCESS_TOKEN" \
|
|
-H "Content-Type: application/json" \
|
|
-d '{
|
|
"log_connections": false
|
|
}'
|
|
```
|
|
|
|
To verify the setting, use the SQL Editor:
|
|
|
|
```sql
|
|
show log_connections;
|
|
```
|