The project Timeout setting controls worker execution time for ordinary site requests. It defaults to 30 seconds and accepts whole seconds from 1 to 180. Queueing and worker startup do not consume this time. The limit includes receiving the worker’s response body.

From your project’s Settings → Instance, edit Timeout (seconds). The change saves automatically when you leave the field. Workspace Admins and Developers with project-write access can change it.

The same setting is available through the API, CLI, and MCP:

  • API: PATCH /v1/projects/{id} with {"timeout":60}. Project-detail responses include timeout. Omit the field to leave it unchanged; null is not accepted.
  • CLI: agiler projects update <project> --timeout 60. Use agiler projects get <project> to view it.
  • MCP: Call projects_update with {"project":"<project>","timeout":60}. Use projects_get to view it.

Commands, SQL statements, backup and restore worker commands, and other internal worker commands use the 180-second maximum, regardless of this setting. SQL and WP-CLI operations still accept an explicit shorter per-operation timeout. The limit applies to each worker command, not the entire multi-stage backup or restore process.

WordPress requests also use the maximum when they carry a wordpress_logged_in_ cookie or target /wp-admin, its descendants, or /wp-cron.php (including path-info suffixes). This is a cookie/path heuristic: it includes non-admin logged-in users and does not verify WordPress roles. Other requests, including anonymous login and REST API requests, use the project setting.

New and existing projects default to 30 seconds. Changes apply to subsequent requests after project settings synchronize to the routers.