Skip to main content
Trigger tasks from your backend: Trigger tasks from inside a run: Additionally, scheduled tasks get automatically triggered on their schedule and webhooks when receiving a webhook.

Scheduled tasks

You should attach one or more schedules to your schedules.task() to trigger it on a recurring schedule. Read the scheduled tasks docs.

Authentication

When you trigger a task from your backend code, you need to set the TRIGGER_SECRET_KEY environment variable. You can find the value on the API keys page in the Trigger.dev dashboard. More info on API keys.

Triggering from your backend

You can trigger any task from your backend code using the tasks.trigger() or tasks.batchTrigger() SDK functions.
Do not trigger tasks directly from your frontend. If you do, you will leak your private Trigger.dev API key.
You can use Next.js Server Actions but you need to be careful with bundling.

tasks.trigger()

Triggers a single run of a task with the payload you pass in, and any options you specify, without needing to import the task.
By using tasks.trigger(), you can pass in the task type as a generic argument, giving you full type checking. Make sure you use a type import so that your task code is not imported into your application.

tasks.batchTrigger()

Triggers multiples runs of a task with the payloads you pass in, and any options you specify, without needing to import the task.
By using tasks.batchTrigger(), you can pass in the task type as a generic argument, giving you full type checking. Make sure you use a type import so that your task code is not imported into your application.

tasks.triggerAndPoll()

Triggers a single run of a task with the payload you pass in, and any options you specify, and then polls the run until it’s complete.
By using tasks.triggerAndPoll(), you can pass in the task type as a generic argument, giving you full type checking. Make sure you use a type import so that your task code is not imported into your application.
The above code is just a demonstration of the API and is not recommended to use in an API route this way as it will block the request until the task is complete.

Triggering from inside a run

Task instance methods are available on the Task object you receive when you define a task. We recommend you use these methods inside another task to trigger subtasks.

yourTask.trigger()

Triggers a single run of a task with the payload you pass in, and any options you specify. It does NOT wait for the result. If called from within a task, you can use the AndWait version to pause execution until the triggered run is complete. If you need to call trigger() on a task in a loop, use batchTrigger() instead which will trigger up to 100 tasks in a single call.
/trigger/my-task.ts

yourTask.batchTrigger()

Triggers multiples runs of a task with the payloads you pass in, and any options you specify. It does NOT wait for the result.
/trigger/my-task.ts

yourTask.triggerAndWait()

This is where it gets interesting. You can trigger a task and then wait for the result. This is useful when you need to call a different task and then use the result to continue with your task.
Instead, use batchTriggerAndWait() if you can, or a for loop if you can’t.To control concurrency using batch triggers, you can set queue.concurrencyLimit on the child task.
/trigger/parent.ts
The result object is a “Result” type that needs to be checked to see if the child task run was successful:
/trigger/parent.ts
If instead you just want to get the output of the child task, and throw an error if the child task failed, you can use the unwrap method:
/trigger/parent.ts
You can also catch the error if the child task fails and get more information about the error:
/trigger/parent.ts
This method should only be used inside a task. If you use it outside a task, it will throw an error.

yourTask.batchTriggerAndWait()

You can batch trigger a task and wait for all the results. This is useful for the fan-out pattern, where you need to call a task multiple times and then wait for all the results to continue with your task.
Instead, pass in all items at once and set an appropriate maxConcurrency. Alternatively, use sequentially with a for loop.To control concurrency, you can set queue.concurrencyLimit on the child task.
When using batchTriggerAndWait, you have full control over how to handle failures within the batch. The method returns an array of run results, allowing you to inspect each run’s outcome individually and implement custom error handling.Here’s how you can manage run failures:
  1. Inspect individual run results: Each run in the returned array has an ok property indicating success or failure.
  2. Access error information: For failed runs, you can examine the error property to get details about the failure.
  3. Choose your failure strategy: You have two main options:
    • Fail the entire batch: Throw an error if any run fails, causing the parent task to reattempt.
    • Continue despite failures: Process the results without throwing an error, allowing the parent task to continue.
  4. Implement custom logic: You can create sophisticated handling based on the number of failures, types of errors, or other criteria.
Here’s an example of how you might handle run failures:
/trigger/nested.ts
This method should only be used inside a task. If you use it outside a task, it will throw an error.

Options

All of the above functions accept an options object:
The following options are available:

delay

When you want to trigger a task now, but have it run at a later time, you can use the delay option:
Runs that are delayed and have not been enqueued yet will display in the dashboard with a “Delayed” status: Delayed run in the dashboard
Delayed runs will be enqueued at the time specified, and will run as soon as possible after that time, just as a normally triggered run would.
You can cancel a delayed run using the runs.cancel SDK function:
You can also reschedule a delayed run using the runs.reschedule SDK function:
The delay option is also available when using batchTrigger:

ttl

You can set a TTL (time to live) when triggering a task, which will automatically expire the run if it hasn’t started within the specified time. This is useful for ensuring that a run doesn’t get stuck in the queue for too long.
All runs in development have a default ttl of 10 minutes. You can disable this by setting the ttl option.
When a run is expired, it will be marked as “Expired” in the dashboard: Expired runs in the dashboard When you use both delay and ttl, the TTL will start counting down from the time the run is enqueued, not from the time the run is triggered. So for example, when using the following code:
The timeline would look like this:
  1. The run is created at 12:00:00
  2. The run is enqueued at 12:10:00
  3. The TTL starts counting down from 12:10:00
  4. If the run hasn’t started by 13:10:00, it will be expired
For this reason, the ttl option only accepts durations and not absolute timestamps.

idempotencyKey

You can provide an idempotencyKey to ensure that a task is only triggered once with the same key. This is useful if you are triggering a task within another task that might be retried:
For more information, see our Idempotency documentation.

queue

When you trigger a task you can override the concurrency limit. This is really useful if you sometimes have high priority runs. The task:
/trigger/override-concurrency.ts
Triggering from your backend and overriding the concurrency:
app/api/push/route.ts

concurrencyKey

If you’re building an application where you want to run tasks for your users, you might want a separate queue for each of your users. (It doesn’t have to be users, it can be any entity you want to separately limit the concurrency for.) You can do this by using concurrencyKey. It creates a separate queue for each value of the key. Your backend code:
app/api/pr/route.ts

maxAttempts

You can set the maximum number of attempts for a task run. If the run fails, it will be retried up to the number of attempts you specify.
This will override the retry.maxAttempts value set in the task definition.

Large Payloads

We recommend keeping your task payloads as small as possible. We currently have a hard limit on task payloads above 10MB. If your payload size is larger than 512KB, instead of saving the payload to the database, we will upload it to an S3-compatible object store and store the URL in the database. When your task runs, we automatically download the payload from the object store and pass it to your task function. We also will return to you a payloadPresignedUrl from the runs.retrieve SDK function so you can download the payload if needed:
We also use this same system for dealing with large task outputs, and subsequently will return a corresponding outputPresignedUrl. Task outputs are limited to 100MB.
If you need to pass larger payloads, you’ll need to upload the payload to your own storage and pass a URL to the file in the payload instead. For example, uploading to S3 and then sending a presigned URL that expires in URL:

Batch Triggering

When using batchTrigger or batchTriggerAndWait, the total size of all payloads cannot exceed 10MB. This means if you are doing a batch of 100 runs, each payload should be less than 100KB.