---
title: Check a workflow run | Lightfield
description: Read the status of an existing workflow run without starting another run.
---

Use [Get workflow run status](/api/resources/workflowRun/methods/status/index.md) to follow an existing run. This endpoint reads status; it does not create a workflow or start a run. For triggers, testing and run history, see [Workflows](/help/settings/workflows/index.md).

## Read the status

Use the run ID from the workflow invocation you are tracking. This status endpoint does not require an API key: anyone with the run ID can read its status. Keep run IDs private. The response contains no run inputs, outputs or workspace details.

Terminal window

```
curl "https://api.lightfield.app/v1/workflowRun/$RUN_ID/status"
```

The response contains a `status` string, for example:

```
{ "status": "STARTED" }
```

Keep the run ID alongside the originating event in your integration. A workflow ID and a run ID identify different things; use the individual run ID here.

## Wait for completion

Poll with a bounded interval and an overall timeout. A `STARTED` response means you should wait, not trigger another run. Treat `COMPLETED` as completion and `FAILED` as a reason to inspect the failed step in the workflow’s run history. `COMPLETED_WITH_RECOVER` means a step needed recovery; inspect the result before treating it as a clean completion. `CANCELLED`, `DISMISSED` and `SKIPPED` also end a run. `NOT_STARTED`, `PAUSED` and `DELAYED` are not completed runs. The schema allows a string rather than a closed enum, so preserve unfamiliar statuses in your application instead of interpreting them as success.

A successful HTTP request confirms that status was read; it does not mean the workflow succeeded. On 404, check that you used a run ID rather than the workflow ID. For temporary server errors, use [bounded retries](/using-the-api/errors/index.md) and keep polling the same run.