internal

Get Marketing Slowest Runs

List the slowest marketing runs whose run falls in week_start's week.

Backs the click-through on the weekly run-latency chart, and answers "which runs took really long, and was it waiting or working?" -- every row breaks end-to-end latency into queue wait and the prep-plus-analysis span, because the same ~40-minute total is a dispatch problem in one run and slow work in another, and the total alone cannot tell them apart.

Uses the same week bucketing (date_trunc('week', run_time)) and the same _latency_filters population as _run_latency_weekly_series, so total equals the clicked point's runs for the same scope -- and the first row under the default sort is the run behind that week's end_to_end_max_seconds. The same survivorship caveat applies: a run that failed or is still stuck has no analysis_completed_at and cannot appear here, however long it has been waiting. Each row carries file_id to deeplink into the file's history view.

Paginated with limit/offset over the full ordered set. The sort key is followed by run_id as a unique tiebreaker so equal latencies cannot shuffle between pages, which would otherwise let a row appear twice or not at all. total is always the whole filtered set, not the page.

get/internal/reliability/marketing/runs/slowest

Query parameters

week_startstring date required

ISO week start (Monday) to drill into

ISO week start (Monday) to drill into

sort'end_to_end' | 'queue'

Ordering for the slowest-marketing-runs drill-down.

end_to_end (default) answers "which analyses took really long?" as the user experienced it -- a run that waited 43 min and one that analysed for 27 min both belong on that list. queue isolates the dispatch-side delay when triaging a suspected queue stall.

Order by end-to-end latency (default) or by queue wait alone

company_idstring uuid nullable
team_idstring uuid nullable
limitinteger
offsetinteger

Response

Successful Response

week_startstring date required
sort'end_to_end' | 'queue' required

Ordering for the slowest-marketing-runs drill-down.

end_to_end (default) answers "which analyses took really long?" as the user experienced it -- a run that waited 43 min and one that analysed for 27 min both belong on that list. queue isolates the dispatch-side delay when triaging a suspected queue stall.

totalinteger required
limitinteger required
offsetinteger required

Changes

No recorded changes to this endpoint across all 2 revisions of this API.