Skip to main content
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: 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: 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

​
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. 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. For scheduling, see Schedule cloud runs. For current interface details, see What is Cloud Live Log & Run History? and Why are subtasks stopped or running fewer than expected? in the Octoparse Help Center.