List Executions - BlobHub

List executions of a specific schedule. Results are sorted by creation time (newest first) and paginated in batches of 10. Executions are fire-and-forget records of past schedule firings.

POST `/revisions/:id/data/query` (Command: `list_executions`)

Request Body

Parameter	Type	Required	Description
`command`	string	Yes	Must be `list_executions`.
`schedule_id`	string	Yes	Id of the schedule whose executions to list.
`start_execution_id`	string	No	Pagination cursor. Pass the `last_execution_id` from the previous page.
`include_schedule`	boolean	No	When `true`, the response also includes the parent `schedule` object.

Response

Parameter	Type	Description
`executions`	array	Execution objects in descending `created_at` order (up to 10 per page).
`last_execution_id`	string / null	Pagination cursor for the next page, or `null` if there are no more pages.
`schedule`	object	Parent schedule object. Only present when `include_schedule` is `true`.

Each execution object has the following shape:

Field	Type	Description
`id`	string	Execution id.
`schedule_id`	string	Id of the parent schedule.
`created_at`	string	ISO 8601 UTC timestamp when the execution was recorded.
`invocation_target_type`	string	Target type, currently `workflow`.
`invocation_target`	object	The invocation target this fire used, as the schedule stored it — the nested `target`, `workflow` and `input_data`, each named as written, with only a pinned target’s `target.session` stored as its id — not what it resolved to on this particular fire.
`description`	string	What this fire sent as `create_execution`’s `description`. Recorded only on a `success` run, or an `invocation_error` run whose `result.error` is `invocation_failed` — the two outcomes reached after the call to `create_execution` — and only when the schedule had one at fire time. Absent on every other run, including a target-resolution failure such as `session_not_open`, whatever the schedule’s own `description`.
`status`	string	`success`, `invocation_error` or `access_error`. See Execution History for what separates them.
`result`	object	`{"error": "<stable name>"}` on failure, optionally with `message` carrying free text; `{"execution": {"id": ...}}` on success. See the `result.error` table in Execution History.

Errors

Status	Error	Cause
403	`forbidden`	The schedule does not exist, or it is not reachable from this revision.

A caller cannot tell these two 403 cases apart — a schedule that does not exist and one that is not reachable both answer forbidden. Sessions already work this way; see Close Session.

Example

{
  "command": "list_executions",
  "schedule_id": "sched-001"
}

{
  "status": "success",
  "executions": [
    {
      "id": "exec-002",
      "schedule_id": "sched-001",
      "created_at": "2026-04-07T13:00:00Z",
      "invocation_target_type": "workflow",
      "invocation_target": {
        "target": {
          "blob": "5b0e7c2a-3f61-4d9b-8a47-2c9e1f6d0b38",
          "revision": "default",
          "session": "scheduled_runs"
        },
        "workflow": {"definition": "daily-report"},
        "input_data": []
      },
      "description": "Daily report for the morning digest.",
      "status": "success",
      "result": {
        "execution": {
          "id": "exec-wf-789"
        }
      }
    },
    {
      "id": "exec-001",
      "schedule_id": "sched-001",
      "created_at": "2026-04-06T13:00:00Z",
      "invocation_target_type": "workflow",
      "invocation_target": {
        "target": {
          "blob": "5b0e7c2a-3f61-4d9b-8a47-2c9e1f6d0b38",
          "revision": "default",
          "session": "scheduled_runs"
        },
        "workflow": {"definition": "daily-report"},
        "input_data": []
      },
      "status": "invocation_error",
      "result": {
        "error": "session_not_open"
      }
    }
  ],
  "last_execution_id": null
}