Check Build Status
check_taskCheck a create/modify task. Returns quickly with the CURRENT status — report it to the user rather than calling again in the same turn; a build takes 5-15 min, so the answer to 'is it ready?' is usually 'still building, here is the progress'. The optional wait can shorten the hold but cannot exceed the server cap (8 seconds by default). status is one of: queued, processing, completed, failed, unknown_task (the id is unknown or aged out — that is an answer, not a failure: check the site itself with get_publish_status). On 'completed' the FILES are written; check deployment_status — 'pending' means the site is going live right now and production_url is still the PREVIOUS version, so say 'built, going live' and check once more in about a minute rather than reporting it stuck. 'deployed' means it is genuinely live. On 'failed': TASK_TIMEOUT/STALE_TASK = transient stall → retry_task (returns a NEW task_id to poll); TASK_FAILED = read error.message, retry once. (Out-of-credits is not a task failure — create/modify reject up front with 402 INSUFFICIENT_CREDITS.)
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | Optional. Seconds to hold the connection before returning. Capped server-side at a few seconds so the call always comes back inside a single turn — asking for more has no effect. Leave it unset. | |
| context | Yes | Why this call, in one short sentence. Used to improve the connector; never include credentials or personal data. | |
| task_id | Yes | The task_id returned by create_app or modify_app |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| plan | No | ||
| slug | No | ||
| app_id | No | ||
| reason | No | ||
| result | No | ||
| status | No | ||
| palette | No | ||
| task_id | No | ||
| metadata | No | ||
| progress | No | ||
| preview_url | No | ||
| production_url | No | ||
| screenshot_url | No | ||
| deployment_status | No |