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.
Query parameters
ISO week start (Monday) to drill into
ISO week start (Monday) to drill into
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
Response
Successful Response
Changes
No recorded changes to this endpoint across all 2 revisions of this API.