signals

List each scout's most recent runs

Return the most recent per_scout_limit runs of every configured scout on the project (default 25), newest-first across the fleet. The per-scout probe is the point: a fleet-wide time window has to serve hourly and weekly scouts from one result cap, so the busy scouts crowd out the sparse ones and a scout's visible history shrinks as the rest of the fleet gets busier. Probing each skill_name gives every scout the same depth of history whatever its schedule, and bounds the response at scouts x per_scout_limit rather than at the fleet's run rate. Only scouts that still have a config are covered, so runs left behind by a deleted or renamed scout are excluded. Runs older than the staleness guard are excluded too, so a scout that stopped running reads as stale instead of healthy — max_age_days (default 30) is that guard's floor, which each scout's own cadence extends. Use list instead when you want a literal time window or a text/emitted filter. Strictly team-scoped.

get/api/projects/{project_id}/signals/scout/runs/recent-per-scout/

Request

  • Base URL: https://us.posthog.com
  • URL: https://us.posthog.com/api/projects/{project_id}/signals/scout/runs/recent-per-scout/
  • Auth: one of:
    • HTTP bearer
    • HTTP bearer

Path parameters

project_idstring required

Project ID of the project you're trying to access. To find the ID of the project, make a call to /api/projects/.

Query parameters

max_age_daysinteger

Floor for the staleness guard on created_at, in days (default 30, hard cap 365). Runs older than the guard are excluded even when a scout has fewer than per_scout_limit newer ones, so a scout that stopped running doesn't report its last runs as current. Each scout's own cadence extends its guard to cover 3 runs' worth of its schedule, so a slow scout on a monthly cron or a 30-day interval keeps its history.

per_scout_limitinteger

How many of each scout's most recent runs to return (default 25, hard cap 100). The count is per scout, so a scout's history depth does not depend on how often the rest of the fleet runs.

Response

Each scout's most recent runs, newest-first across the fleet.

run_idstring required

UUID of the bridge row.

skill_namestring required

Canonical skill name the run executed (e.g. signals-scout-general).

skill_versioninteger required

Skill version snapshotted at run start.

status'not_started' | 'queued' | 'in_progress' | 'completed' | 'failed' | 'cancelled' required
  • not_started - not_started
  • queued - queued
  • in_progress - in_progress
  • completed - completed
  • failed - failed
  • cancelled - cancelled
created_atstring required

ISO-8601 timestamp the bridge row was created — the field date_from / date_to filter and order on. Use this (not started_at) as the date_to cursor when walking past the 100-row cap, so runs created in the gap between a boundary run's TaskRun and its bridge row aren't skipped.

started_atstring required

ISO-8601 timestamp the TaskRun was created.

completed_atstring nullable required

ISO-8601 timestamp the TaskRun completed; null while still running.

task_idstring nullable

UUID of the Tasks Task the scout span ran inside.

task_run_idstring nullable

UUID of the Tasks TaskRun. Pairs with task_id to deep-link.

task_urlstring nullable

Relative deep-link to the Tasks UI for this run, e.g. /project/{team_id}/tasks/{task_id}?runId={task_run_id}.

summarystring required

One-paragraph close-out the scout wrote at end-of-run. Empty string for runs that errored before close-out. The dedupe key for non-emitting runs.

errorstring nullable

Full error_message from the linked TaskRun, surfaced only for failed/cancelled runs (null otherwise, including on success). Use failure_reason for a concise scan-friendly summary.

failure_reasonstring nullable

Concise derived reason the run didn't complete cleanly — the first line of error (bounded), or a status-derived fallback. Null unless the run terminated failed/cancelled. Read this to see at a glance why a run emitted nothing without pulling full stack traces.

emitted_countinteger required

Number of findings this run actually emitted to the inbox. 0 for runs that investigated but surfaced nothing, or ran dry-run / before AI approval. > 0 means the run produced at least one Signal.

emitted_finding_idsstring[] required

The finding_ids behind emitted_count, in emit order. Each maps to a Signal with source_id = run:<run_id>:finding:<finding_id>. Empty for non-emitting runs.

emitted_report_idsstring[] required

The SignalReport ids this run authored directly via the emit_report channel, in emit order. Separate from emitted_finding_ids (weak emit_signal findings) — a report-authoring scout writes a full report here instead. Empty for runs that authored no report.

edited_report_idsstring[] required

The SignalReport ids this run mutated via the edit_report channel (rewrote title/summary and/or appended a note), deduped. Distinct from emitted_report_ids: edit can target any inbox report, so these are generally not reports the run authored. Empty for runs that edited no report.

Changes

No recorded changes to this operation across all 1 revision of this API.