Trigger.dev

Where does Trigger.dev run your report?

Your app sends a task request. In Trigger.dev Cloud, the task code runs on a separate machine managed by Trigger.dev. Your website can show that the report is waiting and let the customer return later.

A task is a piece of code your app can ask to run, such as turning one saved week of bookings into a report. Write it in TypeScript, deploy it separately and decide where the app will save the finished report. Trigger.dev records the run and its attempts. The app still decides who may open the finished file.

How do you run one disposable report?

Start in the development environment with one made-up report request and a destination you can inspect.

1. 1
   Check the test connections

   Use development credentials and a test database and file store. Confirm the report uses made-up data and has no live email, payment or automatic schedule attached. Stop before running if you cannot verify the connections.
2. 2
   Run a task with one test request

   Set up the SDK and task in the app’s code. Run it with the local development CLI and use the task’s test action in the dashboard. Send a report ID so the task can look up the fake records in test storage.
3. 3
   Check the saved result

   Find the run in the dashboard and match its outcome to one report in the test app. Open the file from the test account that asked for it. Keep the result in the app’s storage so access does not depend on the run log.

What does a retry repeat?

An automatic retry gives the task another attempt. A manual replay makes a new run and normally uses the current task version in its environment.

Set the total number of attempts and a wait between attempts. A task that throws an error may run its work again. If it already saved a report or called another service before failing, use the same report ID and reuse the result or the outside service’s operation key.

When you trigger a task, an idempotency key is a label that helps the service recognize a repeat request. The default key lifetime is 30 days and a failed run clears its key. That key does not make the work inside an attempt safe to repeat. Before replaying, check the input, target environment and whether the result already exists.

How do you limit long runs and scheduled work?

Set how long a task may compute and how many reports may run at once. The website’s response timeout and the task’s own limits are separate.

Trigger.dev lets you set a project, task or run duration limit. Some supported waits save the run so the machine can stop computing until it is time to resume. A queued job can also expire before it starts if you configure its waiting limit.

For a weekly report, set the intended time zone. Check the expected time, actual start and last completed report. A schedule that fired may still be waiting for capacity. Send small inputs such as a report ID. The documented single-trigger input limit is 3 MB.

What changes the Trigger.dev Cloud bill?

Cloud pricing counts the run starting on a managed worker and the seconds spent computing on the selected machine. Development runs are outside those managed-worker charges.

Listed dollar prices on November 11, 2026. The default Small 1x machine is listed at $0.0000338 per computing second. Each charged run adds $0.000025 for starting. One hundred runs at 20 seconds each would use about $0.07 of these charges before other usage, taxes or extra processing. Check the machine, actual attempts and separately billed services.

On a small screen, scroll the table sideways to read every column.

What should you keep when tasks move?

Keep your task code and the app’s own report records and files. Check run history promptly when you need to recover a failure.

The Cloud pricing page lists log retention of one day on Free, seven days on Hobby and 30 days on Pro. Keep the app’s important results and the link between each report and its run in storage you control.

Trigger.dev publishes the platform code and documents self-hosting. Running it yourself moves deployment, updates, security and recovery to you. Before switching, account for queued runs, schedules and secrets and verify a test result on the replacement. Do not assume a source-code copy carries open runs or Cloud history across.