--- title: Timeouts subtitle: Extend database timeouts to execute longer transactions --- Requests made through the Supabase API and Dashboard have a timeout of 60 seconds. The database also has a global default timeout of 2 minutes. To execute longer transactions, connect to your database using [Supavisor](/docs/guides/database/connecting-to-postgres#connection-pooler) or the [direct connection string](/docs/guides/database/connecting-to-postgres#direct-connections), and change the timeout settings. ## Change Postgres timeout You can change the Postgres timeout at the: 1. [Session level](#session-level) 1. [Function level](#function-level) 1. [Global level](#global-level) 1. [Role level](#role-level) ### Session level Session level settings persist for the duration of the connection. You must be connecting to the database in session mode for this to take effect. Set the session timeout by running: ```sql set statement_timeout = '10min'; ``` Because this applies to sessions only, it can only be used with connections through Supavisor in session mode (port 5432) or a direct connection. It cannot be used in the Dashboard, with the Supabase Client API, nor with Supavisor in Transaction mode (port 6543). This is most often used for single, long running, administrative tasks, such as creating an HSNW index. Once the setting is implemented, you can view it by executing: ```sql SHOW statement_timeout; ``` See the full guide on [changing session timeouts](https://github.com/orgs/supabase/discussions/21133). ### Function level This works with the Database REST API when called from the Supabase client libraries: ```sql create or replace function myfunc() return void as $$ select pg_sleep(3); -- simulating some long-running process $$ language set statement_timeout TO '4s'; -- set custom timeout ``` This is mostly for recurring functions that need a special exemption for runtimes. ### Global level This changes the statement timeout for all queries. It is only available on Supabase Postgres version 15.1.1.78 and higher. If you are unsure what version you have, check your [Infrastructure Settings](/dashboard/project/_/settings/infrastructure) ```sql alter database postgres set statement_timeout TO '4s'; ``` Check if your changes took effect: ```sql show statement_timeout; ``` ### Role level This sets the timeout for a specific role. It has a higher precedence than the global timeout setting. The default role timeouts are: - `anon`: 3s - `authenticated`: 8s - `service_role`: none (capped by API to be 60s) - `postgres`: none (capped by default global timeout to be 2min) Run the following query to change a role's timeout: ```sql alter role example_role set statement_timeout = '10min'; -- could also use seconds '10s' ``` Unlike global settings, the result cannot be checked with `SHOW statement_timeout`. Instead, run: ```sql select rolname, rolconfig from pg_roles where rolname in ( 'anon', 'authenticated', 'postgres', 'service_role' -- , ); ``` Although not necessary, if you are uncertain if a timeout has been applied, you can run a quick test: ```sql create or replace function myfunc() returns void as $$ select pg_sleep(601); -- simulating some long-running process $$ language sql; ``` ## Identifying timeouts The Supabase Dashboard contains tools to help you identify timed-out and long-running queries. ### Using the Log Explorer Go to the [Log Explorer](/dashboard/project/_/logs/explorer), and run the following query to identify timed-out events (`statement timeout`) and queries that successfully run in greater than 10 seconds (`duration`). ```sql select cast(postgres_logs.timestamp as datetime) as timestamp, event_message, parsed.error_severity, parsed.user_name, parsed.query, parsed.detail, parsed.hint, parsed.sql_state_code, parsed.backend_type from postgres_logs cross join unnest(metadata) as metadata cross join unnest(metadata.parsed) as parsed where regexp_contains(event_message, 'duration|statement timeout') -- (OPTIONAL) MODIFY OR REMOVE and parsed.user_name = 'authenticator' -- <--------CHANGE order by timestamp desc limit 100; ``` ### Using the Query Performance page Go to the [Query Performance page](/dashboard/project/_/database/query-performance?preset=slowest_execution) and filter by relevant role and query speeds. This only identifies slow-running but successful queries. Unlike the Log Explorer, it does not show you timed-out queries. ### Understanding roles in logs Each API server uses a designated user for connecting to the database: | Role | API/Tool | | -------------------------- | ------------------------------------------------------------------------- | | supabase_admin | Used by Supabase to configure projects and for monitoring | | authenticator | PostgREST | | supabase_auth_admin | Auth | | supabase_storage_admin | Storage | | supabase_realtime_admin | Realtime | | supabase_replication_admin | Synchronizes Read Replicas | | postgres | Supabase Dashboard and External Tools (e.g., Prisma, SQLAlchemy, PSQL...) | | Custom roles | External Tools (e.g., Prisma, SQLAlchemy, PSQL...) | Filter by the `parsed.user_name` field to only retrieve logs made by specific users: ```sql -- find events based on role/server ... query where -- find events from the relevant role parsed.user_name = '' ``` ## Resources - [How to interpret and explore the Postgres logs](https://github.com/orgs/supabase/discussions/26224) - [How to interpret and explore the Database API logs](https://github.com/orgs/supabase/discussions/22849) - [How to filter the Log Explorer](https://github.com/orgs/supabase/discussions/22640)