# Canceling statement due to statement timeout

> What the 57014 statement timeout error means, how to check the timeouts set on your project's roles, and how to fix slow queries or raise the limit safely on SupaHost.

Source: https://supahost.app/kb/statement-timeout · Updated 2026-11-11

## What you see

```
ERROR:  57014: canceling statement due to statement timeout
```

Through the Data API it comes back as HTTP 500:

```json
{ "code": "57014", "details": null, "hint": null, "message": "canceling statement due to statement timeout" }
```

It can also show up in Studio's SQL editor, in a migration, or in a cron job's entry in `cron.job_run_details`.

## Why it happens

`statement_timeout` is a Postgres setting that cancels any single statement that runs longer than the limit. It protects the database from runaway queries that hold connections and locks. Timeouts are usually attached to roles, so the limit depends on who runs the query: requests from your app run as `anon` or `authenticated`, while Studio, the SSH tunnel and cron jobs run as `postgres`.

The query is either genuinely slow (a missing index, a big table scan, an RLS policy that does work per row) or doing a job that's meant to take a while, like a backfill.

## How to fix it

1. Check which timeouts apply. SupaHost doesn't set its own; the values come from the Supabase Postgres image, so look rather than assume:

   ```sql
   select rolname, rolconfig
   from pg_roles
   where rolname in ('anon', 'authenticated', 'service_role', 'authenticator', 'postgres');

   show statement_timeout;  -- the value for your current session
   ```

2. Make the query faster first. Run it with `explain analyze` and look for sequential scans on large tables:

   ```sql
   explain analyze
   select * from public.bookings
   where venue_id = 42 and starts_at >= now()
   order by starts_at
   limit 50;
   ```

   An index on the filtered columns often turns seconds into milliseconds:

   ```sql
   create index concurrently if not exists bookings_venue_starts_idx
     on public.bookings (venue_id, starts_at);
   ```

3. For a one-off long job in the SQL editor or psql, raise the limit for that session only:

   ```sql
   set statement_timeout = '15min';
   update public.bookings set status = 'archived' where starts_at < now() - interval '2 years';
   ```

   In a cron job, put the `set` at the start of the job's SQL. Each statement in the command gets its own timer, so the setting applies to the statements after it.

4. If an API role's limit is too low for legitimate requests, raise it for that role and tell the Data API to reload its config:

   ```sql
   alter role authenticated set statement_timeout = '15s';
   notify pgrst, 'reload config';
   ```

   Keep API timeouts short. A long timeout on `anon` lets anyone tie up your connections with slow requests.

5. Big batch work is better split into chunks (for example 5,000 rows per statement) than run as one huge statement.

## On SupaHost

- Each project's Data API has a pool of 5 database connections. A few requests stuck on slow queries can make every other request for that project wait, and they may fail with `PGRST003` (timed out waiting for a connection) instead. Fixing the slow query fixes both.
- All projects on an instance share one VM, so a slow query in one project uses CPU the others need. To see what's running across the instance, use the queries in [High CPU usage on your instance](/kb/high-cpu).
- Studio opens from *Dashboard → your project → **Database** tab → Open Studio* (owner only).

## Related

- [Connections and timeouts](/docs/database/connections-and-timeouts)
- [Speeding up slow queries with indexes](/kb/improve-query-performance)
- [Query performance and EXPLAIN](/docs/database/query-performance)
- [RLS performance best practices](/kb/rls-performance)