> ## 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.

# Example: scheduled monitoring workflow

> This example shows how Titan is used for repeated collection over time rather than a single scrape.

## Scenario

You want to monitor a product page every hour, keep a stable execution history, and export recurring results for downstream analysis.

## Architecture

```mermaid theme={null}
flowchart LR
    Task[Scheduled task] -->|Every hour| Exec1[Execution 1]
    Task -->|Every hour| Exec2[Execution 2]
    Task -->|Every hour| ExecN[Execution N]
    Exec1 --> Dataset1[Dataset 1]
    Exec2 --> Dataset2[Dataset 2]
    ExecN --> DatasetN[Dataset N]
```

## Recommended request flow

| Step | API call or concept                                           |
| ---- | ------------------------------------------------------------- |
| 1    | `POST /api/v1/tasks` with `execution_type: "scheduled"`       |
| 2    | Monitor executions through `GET /api/v1/tasks/:id/executions` |
| 3    | Inspect completed datasets and exports                        |

## Example task

```bash theme={null}
curl -X POST "$TITAN_API_URL/api/v1/tasks" \
  -H "Authorization: Bearer $TITAN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Hourly price monitor",
    "urls": ["https://example.com/product/123"],
    "objective": "Track the current price and availability",
    "output_schema": {
      "type": "object",
      "properties": {
        "price": { "type": "string" },
        "in_stock": { "type": "boolean" },
        "checked_at": { "type": "string" }
      }
    },
    "execution_type": "scheduled",
    "schedule": "0 * * * *"
  }'
```

## Why scheduling changes the integration model

In a scheduled workflow:

* The task becomes the durable definition
* Executions become the runtime history
* Datasets become the user-facing accumulated output

That means downstream systems should anchor on the task identity and consume many executions over time.

## Good practices for scheduled tasks

| Practice                                     | Why it matters                                 |
| -------------------------------------------- | ---------------------------------------------- |
| Keep one stable task ID                      | Preserves historical continuity                |
| Keep the schema stable                       | Simplifies analytics and downstream processing |
| Use execution history for runtime visibility | Avoids mixing runtime and definition concerns  |
| Use dataset exports for downstream pipelines | Reduces the need to process each run manually  |

## Next steps

* [Run one-off and scheduled tasks](/use-the-platform/run-one-off-and-scheduled-scrapes)
* [Monitor and control executions](/use-the-platform/monitor-and-control-executions)
* [Download results and access media](/use-the-platform/download-results-and-access-media)