What you will be able to do
- Grant the right privileges to create and run serverless and user-managed tasks
- Explain who a task runs as, and what happens when its owner role changes
- Troubleshoot a task that did not run using TASK_HISTORY and a step-by-step checklist
- Separate queuing time from execution time and diagnose timeouts
1.Privileges for creating tasks
Which privileges a role needs to create a task depends on the task's compute model. Every task needs USAGE on its database and schema, plus CREATE TASK on the schema. The compute model adds one more privilege on top of that:
| Object | Privilege | When required |
|---|---|---|
| Account | EXECUTE MANAGED TASK | Only for tasks that use serverless compute |
| Database | USAGE | Always |
| Schema | USAGE, CREATE TASK | Always |
| Warehouse | USAGE | Only for tasks that use user-managed warehouses |
Snowflake suggests putting these grants in custom roles. A warehouse_task_creation role receives CREATE TASK on a schema and USAGE on a warehouse. A serverless_task_creation role receives CREATE TASK and the account-level EXECUTE MANAGED TASK, which only ACCOUNTADMIN grants in the documented example.
GRANT EXECUTE MANAGED TASK ON ACCOUNT
TO ROLE serverless_task_creation;Checkpoint 1 of 7· Check yourself
A role has USAGE on the database and schema, CREATE TASK on the schema, and USAGE on warehouse1. Which kind of task can it create?
Warehouse USAGE is enough to create a user-managed task. A serverless task would also need the account-level EXECUTE MANAGED TASK privilege, which this role does not have.
“Required only for tasks that rely on serverless compute resources.”Source: docs.snowflake.com
Sources1
2.Privileges for running, operating and viewing tasks
Creating a task and running it are checked separately. Once the task exists, its owner role needs the account-level EXECUTE TASK privilege. Serverless tasks also need EXECUTE MANAGED TASK. The owner role also needs USAGE on the database, the schema and, for user-managed tasks, the warehouse, together with whatever privileges the task's own SQL requires. If you revoke EXECUTE TASK from a role, no later run under that role can start. Snowflake checks these privileges again whenever the task is resumed.
The documented pattern is a taskadmin role that holds both account privileges. You then grant that role to each task-owner role, and revoking it removes the ability to run.
USE ROLE accountadmin;
GRANT EXECUTE TASK, EXECUTE MANAGED TASK ON ACCOUNT TO ROLE taskadmin;Other roles can be given narrower access:
- Operate. A role with OPERATE on the task, plus USAGE on its database and schema, can suspend and resume it.
- View. Seeing tasks requires ACCOUNTADMIN, OWNERSHIP of the task, or the global MONITOR EXECUTION privilege.
Who the task runs as. By default, a task runs as a system service that uses the owner role's privileges. Dropping or locking a user therefore does not stop it, and its query history shows the user as SYSTEM. EXECUTE AS USER makes the task run on behalf of a named user instead. That supports secondary roles, user-based masking and row access policies, and a clear audit trail. It requires two grants: the owner role needs IMPERSONATE on the user, and the user needs the owner role.
Ownership changes. If you drop a task's owner role, ownership moves to the role that dropped it, and the task pauses until the new owner resumes it. A run that is already in progress finishes under the dropped role. Every task in a task graph must have the same owner. Transfer the whole graph at once with GRANT OWNERSHIP on all tasks in the schema. Transferring a single task cuts its links to parent and child tasks.
Checkpoint 2 of 7· Check yourself
An operations team should be able to pause and restart a nightly task, but must not own it. What is the minimum they need?
Besides the owner, a role with OPERATE on the task can suspend or resume it, provided it also has USAGE on the containing database and schema. It needs no other privileges.
“a role that has the OPERATE privilege on the task can suspend or resume the task.”Source: docs.snowflake.com
Checkpoint 3 of 7· Exam question
A role named `etl_dev` must be able to create (but not yet run) a serverless task in schema `ETL.JOBS`. Select THREE privileges that the role needs for this.(Select 3)
Correct answers: A, B, C — CREATE TASK on schema ETL.JOBS so the role may define new task objects in the schema.; EXECUTE MANAGED TASK on the account so the role may create tasks that use Snowflake-managed compute.; USAGE on database ETL and on schema ETL.JOBS so the role can reach the schema where the task is created.
- A. Correct: CREATE TASK on the schema is the object-level privilege required to create any task, serverless or not.
- B. Correct: EXECUTE MANAGED TASK is the account-level privilege that allows a role to create serverless tasks that run on Snowflake-managed compute.
- C. Correct: the role needs USAGE on the parent database and schema to resolve the location where the task is created.
- D. Incorrect: a serverless task has no warehouse, so warehouse USAGE is a requirement for user-managed tasks only.
- E. Incorrect: MONITOR EXECUTION only lets a role view task and pipe executions; it does not grant the ability to create tasks.
3.Troubleshooting a task that did not run
When a task does not behave as expected, Snowflake recommends a methodical check. Start with the TASK_HISTORY table function. It records scheduled and completed times, error codes and messages. It also separates two cases that look alike: a task that never ran, and a task that ran but whose SQL failed.
select name, query_id, state, scheduled_time, error_message from table(information_schema.task_history(task_name => 'my_task'));If the history shows no run, work through the rest of the checklist in order:
1. Predecessor. If the task is in a graph, confirm its predecessor succeeded. A child task is skipped when its parent fails.
2. State. Confirm with SHOW TASKS or DESCRIBE TASK that the task is RESUMED, or that someone ran it with EXECUTE TASK.
3. Schedule. Check the cron expression, and confirm that at least one scheduled time has actually passed.
4. Privileges. Confirm the owner role's privileges with SHOW GRANTS TO ROLE.
5. Stream. For a WHEN SYSTEM$STREAM_HAS_DATA task, confirm the stream held CDC records at the scheduled time. An AT | BEFORE clause shows the stream's historical data.
To see who ran a task, use SHOW TASKS or DESCRIBE TASK. The OWNER column shows the owner role. The EXECUTE_AS_USER column is NULL unless the task impersonates a user. In the QUERY_HISTORY view, a task that did not run as an actual user shows SYSTEM as the user.
Checkpoint 4 of 7· Put it in order
Order Snowflake's troubleshooting steps for a task that did not run
- 1.Check the cron expression and that a scheduled time has passed
- 2.Verify the task is RESUMED with SHOW TASKS or DESCRIBE TASK
- 3.Verify the owner role's privileges with SHOW GRANTS TO ROLE
- 4.Query the TASK_HISTORY table function
- 5.Check that any predecessor task completed successfully
The method starts from the evidence in TASK_HISTORY. It then rules out an upstream failure, a suspended task, a schedule that has not fired yet, and finally missing privileges.
“Query the TASK_HISTORY table function to verify the task did not run.”Source: docs.snowflake.com
Checkpoint 5 of 7· Exam question
A developer ran CREATE TASK with SCHEDULE = '5 MINUTE' using a role that has every required privilege. An hour later TASK_HISTORY shows no runs for the task. What is the MOST likely cause and fix?
Correct answer: A — The task was created in a suspended state, so the owner role, which also holds EXECUTE TASK, must run ALTER TASK ... RESUME to start scheduling.
- A. Correct: tasks are created suspended and are only scheduled after ALTER TASK ... RESUME, which requires the owner role to hold the account-level EXECUTE TASK privilege.
- B. Incorrect: an interval schedule does not wait for a manual run; once a task is resumed, the scheduler triggers it on its own.
- C. Incorrect: ALLOW_OVERLAPPING_EXECUTION only affects what happens when a prior run is still going; it cannot block a first run that was never scheduled.
- D. Incorrect: tasks resume their warehouse automatically when they run, and no manual warehouse resume or OPERATE grant is needed.
4.Reading run duration and fixing timeouts
A task's duration is measured from its scheduled start to its completion, and it has two parts that TASK_HISTORY lets you separate:
- Queuing time runs from SCHEDULED_TIME to QUERY_START_TIME. It tends to be long for user-managed tasks on a shared or busy warehouse. Serverless tasks scale to meet their target completion interval, and that interval includes queuing. - Execution time runs from QUERY_START_TIME to COMPLETED_TIME.
A single run is limited to 60 minutes by default. If history shows runs being cancelled or overrunning their window, the cause is often an undersized warehouse. You can make the warehouse bigger, or raise the limit with ALTER TASK … SET USER_TASK_TIMEOUT_MS. Neither change helps if the SQL itself has parallelization problems, and in that case you should rewrite the statement. To see whether a timeout has been set on a task, run:
SHOW PARAMETERS LIKE 'USER_TASK_TIMEOUT_MS' IN TASK <task_name>;Checkpoint 6 of 7· Check yourself
SHOW PARAMETERS LIKE 'USER_TASK_TIMEOUT_MS' IN TASK nightly_load returns no record. What timeout applies to each run?
When the statement returns no record, the task has not overridden the parameter, so the 60-minute default applies.
“If the statement returns no record, the task currently has the default 3600000 millisecond (60 minute) timeout.”Source: docs.snowflake.com
Session timeouts interact with the task timeout. If both STATEMENT_TIMEOUT_IN_SECONDS and USER_TASK_TIMEOUT_MS are set, the lower non-zero value wins. If STATEMENT_QUEUED_TIMEOUT_IN_SECONDS is set alongside USER_TASK_TIMEOUT_MS, USER_TASK_TIMEOUT_MS takes precedence.
Checkpoint 7 of 7· Match them up
Match each diagnostic question to what answers it
Tap a term, then the definition that fits it.
TASK_HISTORY's timestamps split queuing from execution. The two timeout precedence rules work differently, which is why they are worth memorising separately.
“When both STATEMENT_TIMEOUT_IN_SECONDS and USER_TASK_TIMEOUT_MS are set, the timeout is the lowest non-zero value of the two parameters.”Source: docs.snowflake.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Every task creator needs EXECUTE MANAGED TASK.Why is that wrong?
EXECUTE MANAGED TASK is only needed for serverless tasks. A user-managed task needs USAGE on its warehouse instead.
Covered in Privileges for creating tasks
2.After the owner role is dropped, the task keeps running on schedule under the role that dropped it.Why is that wrong?
Ownership does move to the role that dropped the owner, but the task is paused automatically. It does not run again until the new owner resumes it.
Covered in Privileges for running, operating and viewing tasks
3.A task that keeps timing out will always be fixed by a larger warehouse or a longer USER_TASK_TIMEOUT_MS.Why is that wrong?
Neither change helps when the SQL has parallelization problems. In that case the statement itself needs rewriting.
Covered in Reading run duration and fixing timeouts
Practise it for real
Create a serverless task, test it, inspect its history and enable it, using a role that holds CREATE TASK and EXECUTE MANAGED TASK
1.Run CREATE TASK SCHEDULED_T1 SCHEDULE='60 MINUTES' AS SELECT 1; without a WAREHOUSE parameter
Why: Leaving out WAREHOUSE makes the task serverless
You should see: The task is created in the SUSPENDED state
2.Run EXECUTE TASK SCHEDULED_T1;
Why: A one-off run tests the task before you enable its schedule
You should see: A single run is scheduled even though the task is still suspended
3.Query table(information_schema.task_history(task_name => 'SCHEDULED_T1')) for name, query_id, state, scheduled_time and error_message
Why: TASK_HISTORY is the first place to look when checking any task run
You should see: A row for the manual run, showing its state and an empty error_message if it succeeded
4.Run SHOW PARAMETERS LIKE 'USER_TASK_TIMEOUT_MS' IN TASK SCHEDULED_T1;
Why: Confirms which timeout limits the task's runs
You should see: No record, meaning the 60-minute default applies
5.Run ALTER TASK SCHEDULED_T1 RESUME;
Why: Resuming lets the task follow its schedule from now on
You should see: SHOW TASKS reports the task as resumed, and it runs every hour
Stuck? Get a nudge
If EXECUTE TASK fails with a privilege error, check that the owner role has both EXECUTE TASK and EXECUTE MANAGED TASK on the account.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://docs.snowflake.com/en/user-guide/tasks-introOfficial docs
“Snowflake requires different permissions to create serverless and user-managed tasks.”
↩︎ Privileges for creating tasks“Revoking the EXECUTE TASK privilege on a role prevents all subsequent task runs from starting under that role.”
↩︎ Privileges for running, operating and viewing tasks“The owner role of the task must be granted the IMPERSONATE privilege on the user specified by EXECUTE AS USER”
↩︎ Privileges for running, operating and viewing tasks“For user-managed tasks, longer queueing periods are common when tasks are scheduled to run on a shared or busy warehouse.”
↩︎ Reading run duration and fixing timeouts“Required only for tasks that rely on serverless compute resources.”
↩︎ Exam trap 1“When a task transfers ownership, it is automatically paused and new task runs aren’t scheduled until the new owner resumes the task.”
↩︎ Exam trap 2“Required only for tasks that rely on serverless compute resources.”
↩︎ Checkpoint“a role that has the OPERATE privilege on the task can suspend or resume the task.”
↩︎ Checkpoint“When both STATEMENT_TIMEOUT_IN_SECONDS and USER_TASK_TIMEOUT_MS are set, the timeout is the lowest non-zero value of the two parameters.”
↩︎ Checkpoint - 2.
“All tasks in a task graph must have the same task owner and be stored in the same database and schema.”
↩︎ Privileges for running, operating and viewing tasks - 3.https://docs.snowflake.com/en/user-guide/tasks-tsOfficial docs
“It is possible that the task ran successfully but the SQL statement in the task definition failed.”
↩︎ Troubleshooting a task that did not run“There is a 60 minute default limit on a single run of a task.”
↩︎ Reading run duration and fixing timeouts“neither increasing the warehouse size nor increasing the timeout limit might help if there are query parallelization issues.”
↩︎ Exam trap 3“Query the TASK_HISTORY table function to verify the task did not run.”
↩︎ Checkpoint“If the statement returns no record, the task currently has the default 3600000 millisecond (60 minute) timeout.”
↩︎ Checkpoint - 4.
“If the task is not run as an actual user, the QUERY EXECUTED BY TASK column displays the user name as “SYSTEM”.”
↩︎ Troubleshooting a task that did not run