---
title: "Get Marketing Slowest Runs"
method: GET
path: "/internal/reliability/marketing/runs/slowest"
tags: ["internal"]
---

# Get Marketing Slowest Runs

`GET /internal/reliability/marketing/runs/slowest`

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

- `week_start` string, date, required — 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.
- `company_id` string, uuid, nullable
- `team_id` string, uuid, nullable
- `limit` integer
- `offset` integer

## Response `200`

Successful Response

- SlowRunsResponse — Paginated slowest marketing runs whose run falls in the clicked ISO week. `total` is every run the week's latency stats were computed over -- the whole filtered set, not the page -- so it equals that week's `WeeklyRunLatencyPoint.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`. `runs` is the `offset`..`offset+limit` slice, ordered by the sort key then `run_id` so paging is stable.
  - `week_start` string, 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.
  - `total` integer, required
  - `limit` integer, required
  - `offset` integer, required
  - `runs` SlowRun[], required
    - `run_id` string, uuid, required
    - `company_id` string, uuid, required
    - `company_name` string, required
    - `file_id` string, uuid, nullable, required
    - `filename` string, nullable, required
    - `run_time` string, date-time, required
    - `analysis_started_at` string, date-time, required
    - `analysis_completed_at` string, date-time, required
    - `queue_seconds` number, required
    - `analysis_seconds` number, required
    - `end_to_end_seconds` number, required

## Other responses

- `422` — Validation Error

---

[API](https://skmtc.dev/kobaltlabs/apis/fastapi.md) · [All operations](https://skmtc.dev/kobaltlabs/apis/fastapi/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/kobaltlabs/fastapi/revisions/f85ef083df64/schema)