Skip to main content
T3 fan-out Β· strategy / product marketing: the flagship for_each. The number of pages is decided at RUNTIME by the competitor’s sitemap; max_parallel keeps the crawl polite, fail_fast: false keeps one dead page from killing the radar, retry: absorbs the flaky web.

The job

Monday 8am: what did they ship? Instead of 40 tabs, the sitemap is mapped, the 8 freshest pages are read concurrently, and one brief tells you what it signals. Every page that survives lands in the fan-in; every page that doesn’t is reported, not fatal.

The shape

The file

competitor-radar.nika.yaml

How it works

1

The collection is computed, not hardcoded

The URL list crosses the boundary (map_recent: ${{ tasks.map.recent }} in with:), then for_each: ${{ with.map_recent }} fans out: eight URLs this week, three next week. The DAG doesn’t change.
2

Resilience is per-iteration

retry: (exponential + jitter) and timeout: "30s" apply to EACH page fetch. fail_fast: false collects errors instead of aborting the batch.
3

The fan-in is just a reference

${{ tasks.pages.output }} is the ARRAY of per-page outputs, in input order. One prompt consumes the whole crawl.

Constructs you just used

Make it yours

  • Track THREE competitors: lift the sitemap URL into a list and nest the pattern, or run the workflow per competitor and merge the briefs.
  • Filter the sitemap by date with a sharper jq binding before fanning out.
  • Schedule it for Monday 07:30 from your host’s cron. The brief is on your desk before standup.

Next Β· Localization factory

Chained fan-outs and the jq transpose zip: the whole docs tree, translated.