> ## Documentation Index
> Fetch the complete documentation index at: https://webscraping.titannet.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Run one-off and scheduled tasks

> Immediate runs versus recurring schedules: same task and execution model for classic extraction and modular workflows.

The difference is not only **when** work runs. It shapes how you think about **task ownership**, **execution history**, and how downstream systems consume **datasets** over time.

## One-off runs

One-off execution is best for:

* Ad hoc extraction or discovery
* Testing a new schema or modular plan
* Running a job on demand
* Collecting a one-time snapshot

The usual pattern is:

1. Create a task
2. Trigger execution manually
3. Monitor the execution
4. Download results

## Scheduled runs

Scheduled execution is best for:

* Ongoing monitoring
* Recurring collection
* Change detection
* Dataset accumulation over time

In a scheduled workflow, the **task** remains stable while the platform creates **new executions** according to the configured schedule.

## Why the distinction matters

Both paths use the same **task** and **execution** objects, but they serve different operating models:

* One-off tasks emphasize **immediate** output.
* Scheduled tasks emphasize **repeatability** and a **history** of runs.

That distinction matters for downstream consumers: one-off work is often consumed as a **single export**, while scheduled work is often consumed as a **time series** of executions or datasets.

## Triggering execution

Manual task runs typically use:

```bash theme={null}
curl -X POST "$TITAN_API_URL/api/v1/tasks/$TASK_ID/run" \
  -H "Authorization: Bearer $TITAN_TOKEN"
```

You can also trigger work through **execution** endpoints, depending on your integration style (see the API Reference).

## Scheduling guidance

When using schedules:

* Keep the **output schema** stable when consumers depend on a fixed shape.
* Keep the **task identity** stable so history stays grouped.
* Treat **executions** as the units of runtime history.

That yields a clearer long-term dataset model and simpler monitoring.

## Next steps

* [Monitor and control executions](/use-the-platform/monitor-and-control-executions)
* [Example: scheduled monitoring workflow](/examples/example-scheduled-monitoring-workflow)
* [Executions](/about-platform/executions)