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

# Monitor cloud runs

> Use Cloud Run Details to monitor Octoparse cloud runs, inspect data and subtasks, diagnose CAPTCHA and failures, and verify recent results before export.

Cloud Run Details is the main workspace for checking a cloud run while it executes and after it finishes. It combines run-level metrics with data, subtask status, event logs, screenshots, and recent run history.

Use it to answer two separate questions:

1. **Did the run execute as expected?** Check status, timing, speed, subtasks, logs, and CAPTCHA attempts.
2. **Is the result ready to use?** Check data volume, duplicates, the Data List, storage completion, and the run you want to export.

## Open Cloud Run Details

When you start a task in the cloud, Octoparse can open the run window automatically. You can also open it from the cloud-run control for the task in the Task List. To review an older execution, open the task's **Recent Runs** or cloud run history and select the run.

The run window is scoped to one cloud run. If the task has been run several times, confirm the task, run time, and batch before interpreting its metrics.

## Read the run summary

The summary at the top of Cloud Run Details gives a quick health check:

| Metric                    | What it tells you                                                                                                      |
| ------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| **Data volume**           | The amount of data produced by the run. Compare it with a representative run or expected range.                        |
| **Task status**           | Whether the run is waiting, running, completed, stopped, failed, or otherwise still processing.                        |
| **Duplicate count**       | Records identified as duplicates during the run. A high value can explain why saved data is lower than extracted data. |
| **Time spent**            | The elapsed time for the run. Use it with data volume to spot unusually slow runs.                                     |
| **Average running speed** | The average extraction rate during the run. It is a run-level average, not a guarantee for every page or subtask.      |

Do not judge success from one metric. A run can show a completed execution while data is still being written, statistics are still updating, or an export cursor has not advanced. Check the result view before treating the run as ready for downstream use.

## Use the run detail areas

### Task Overview

Task Overview provides the run timeline and high-level execution signals, including:

* Run initiated time
* Start time and end time
* Distinct data
* CAPTCHA attempts

Use the timeline to separate queue time from execution time. A long wait before start usually points to capacity or concurrency limits; a long execution interval points to the task, target site, browser, or network path.

CAPTCHA attempts are a signal, not a success guarantee. If attempts increase while output falls or the run slows, inspect the affected subtasks and consider the target site's blocking behavior, IP pool, pacing, and login state.

### Data List

Data List shows the records scraped by the selected cloud run. Use it to verify:

* Expected fields are present and populated.
* Pagination or detail-page loops reached the expected records.
* The output is not mostly duplicate or empty records.
* The selected run contains the data you intend to export.

Data List is a result view. It does not replace run status or subtask diagnostics. If the list is empty, check whether the task failed before extraction, whether the run is still storing data, or whether the workflow returned no records.

### Subtask Status

Subtask Status shows how a split cloud run progressed across its execution units. For each subtask, inspect the available:

* Start and end time
* Elapsed time
* Status
* Data extracted
* Details, including event logs and error screenshots

The number of running subtasks is also a useful view of node use. A task may have many subtasks but only some running at once because of plan capacity, task settings, queueing, or temporary resource availability.

Use **Restart** only after checking the subtask details. Restarting a failed unit without fixing the selector, login, CAPTCHA, or target-site issue can reproduce the same failure.

Common stop reasons include:

| Stop reason             | What it usually means                                                                                                                                                                                                                                                           |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **NoDataFor15Minute**   | The subtask produced no data for 15 minutes and was stopped to avoid holding a cloud node indefinitely. The cause may be a blocked page, missing content, an overloaded page, a browser that did not start, or a Load more / infinite-scroll step that stopped making progress. |
| **ExecutorCrashed**     | The cloud executor or browser process stopped unexpectedly. A heavy page, task configuration, or node resource pressure may be involved.                                                                                                                                        |
| **FromCloudExecutor**   | The cloud executor reported an execution error. Open Details to identify the failed action.                                                                                                                                                                                     |
| **SubTaskRetryLimited** | The subtask remained unsuccessful after the available retries. Fix the underlying task or access issue before restarting it.                                                                                                                                                    |
| **Manual**              | The subtask was stopped by a user action. It is not, by itself, an execution error.                                                                                                                                                                                             |

These labels describe the subtask outcome. Always read the event log and screenshot before deciding whether to retry.

### Recent Runs

Recent Runs lists the task's historical cloud executions. Use it to compare:

* The latest run with the last known good run
* Runtime and average speed over time
* Data volume and duplicate count
* Completed, stopped, failed, or queued outcomes
* Which run should be exported

When you need only one run's output, use its **Export Data** action instead of exporting the task's combined data. Confirm the run date and batch before exporting.

The cloud live log shows the most recent 1,000 events and retains them for 48 hours. Export or record important logs while they are available, especially when investigating a scheduled run.

## Diagnose common signals

| Signal                                            | Likely interpretation                                                                                    | Next check                                                                       |
| ------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| Run remains queued                                | Nodes or the account's parallel-task limit are occupied.                                                 | Check Subtask Status, other active tasks, and queue priority.                    |
| Run starts but has no data                        | The workflow may stop before extraction, return no matches, or fail during loading or login.             | Check Task Overview, event logs, screenshots, and Data List.                     |
| Data volume is lower than expected                | Pagination, detail-page navigation, filters, stopping conditions, or blocking may have limited the run.  | Compare a good run and inspect the first affected subtask.                       |
| Duplicate count is high                           | The run found records already stored for the task, or the workflow revisited the same items.             | Compare distinct data with extracted data and review URL/input deduplication.    |
| Speed is low                                      | The target site, browser waits, sequential steps, CAPTCHA, or limited parallelism may be the bottleneck. | Compare subtask times, CAPTCHA attempts, and the task's split behavior.          |
| Some subtasks stopped                             | A subtask may have encountered no data, blocking, a timeout, or a cloud-node failure.                    | Open its Details, read the event log, and view the screenshot before restarting. |
| Status says complete but data is incomplete       | Execution, storage, statistics, and export become ready at different times.                              | Confirm Data List and storage results, then retry the read or export.            |
| Event log shows HTTP 403 or an access-denied page | The target site may be blocking the cloud request or the selected region.                                | Check the screenshot, IP pool, proxy, login, and request pacing.                 |

## Follow the data and status timeline

Cloud run status and data availability do not advance as one transaction. A useful verification sequence is:

1. The run is accepted and its task or batch is created.
2. Subtasks are created and assigned for execution.
3. Nodes execute the workflow and report extracted data.
4. Data is uploaded and written to cloud storage.
5. Statistics update extracted, saved, and duplicate counts.
6. The run and its data become available for reading or export.

If these signals disagree, use the most specific view for the question: use run details for execution, Subtask Status for partial failures, Data List for records, and Recent Runs for historical comparison. A page label alone is not enough to prove that all data has been stored and is export-ready.

## Recommended monitoring workflow

For a new or changed task:

1. Run a representative sample locally.
2. Start one cloud run and watch Task Overview until execution begins.
3. Check Subtask Status for node allocation, split behavior, and early errors.
4. Compare Data List and data volume with the local sample.
5. Review CAPTCHA attempts, duplicate count, elapsed time, and average speed.
6. Wait for storage to complete before exporting.
7. Save the run as a comparison point for future scheduled runs.

For a recurring task, review Recent Runs after each early recurrence and whenever the target website changes. If a run fails repeatedly, pause the schedule, inspect the first failing subtask, correct the task or access configuration, and run a manual cloud test before enabling the schedule again.

For queue and node behavior, see [Cloud resources and queues](/docs/en/platform/cloud-resources-and-queues). For scheduling, see [Schedule cloud runs](/docs/en/platform/cloud-schedules). For current interface details, see [What is Cloud Live Log & Run History?](https://helpcenter.octoparse.com/en/articles/6470914-what-is-cloud-live-log-run-history) and [Why are subtasks stopped or running fewer than expected?](https://helpcenter.octoparse.com/en/articles/12113754-why-are-subtasks-stopped-or-running-fewer-than-expected) in the Octoparse Help Center.
