How Many Tasks Fire in the Same Minute — Flattening Cowork Scheduled-Task Collisions from Cron

Visualize how many run per minute, window by window

Once you know the maximum, you want to see the congestion as a surface. Build a load array for all 1440 minutes of the day and pull out only the busy stretches into a table.

// Return a 1440-element array of how many runs occupy each minute
function loadProfile(intervals: Interval[]): number[] {
  const load = new Array<number>(1440).fill(0);
  for (const iv of intervals) {
    const end = Math.min(iv.end, 1440);
    for (let m = iv.start; m < end; m++) load[m]++;
  }
  return load;
}
 
// Merge contiguous minutes whose load is at least the threshold into windows
function congestedWindows(load: number[], threshold: number) {
  const windows: { from: number; to: number; peak: number }[] = [];
  let m = 0;
  while (m < load.length) {
    if (load[m] >= threshold) {
      const from = m;
      let peak = 0;
      while (m < load.length && load[m] >= threshold) {
        peak = Math.max(peak, load[m]);
        m++;
      }
      windows.push({ from, to: m - 1, peak });
    } else {
      m++;
    }
  }
  return windows;
}

Call congestedWindows(load, 2) and the stretches where "two or more run at once" come out grouped. When I ran this against my own setup, it was instantly clear the peak was skewed to the evening, roughly 19:30–20:20. Staring at the crons by hand, I had never once noticed that skew.

Keep premium slots fixed, move only the flexible tasks

Here is the heart of the design decision. If you move tasks blindly to cut the peak, the premium article generation slots drift too, and they stop publishing in the window you aimed for. In the Dolice setup I draw an explicit line with a protected flag: premium slots are protected, and only free generation and supporting tasks are treated as movable.

Greedily, we nudge each movable task toward "the emptiest nearby minute," one at a time. The trick is to lay down the fixed tasks' load first, then place the movable tasks into low-load positions in order.

function staggerOffsets(tasks: Task[], windowMin = 90): Map<string, number> {
  const chosen = new Map<string, number>();
 
  const fixed = tasks.filter((t) => t.protected);
  const movable = tasks.filter((t) => !t.protected);
 
  // Lay down the load of the fixed tasks (premium slots, etc.) first
  const base = loadProfile(runIntervals(fixed));
 
  for (const t of movable) {
    const start = fireMinutes(t.cron)[0]; // assume one fire per day
    let bestOffset = 0;
    let bestPeak = Infinity;
 
    for (let off = -windowMin; off <= windowMin; off++) {
      const s = start + off;
      if (s < 0 || s + t.durationMin > 1440) continue;
 
      // Max load across the minutes this candidate position would occupy
      let localPeak = 0;
      for (let m = s; m < s + t.durationMin; m++) {
        localPeak = Math.max(localPeak, base[m]);
      }
 
      // On a tie, prefer the offset closest to the original time
      const better =
        localPeak < bestPeak ||
        (localPeak === bestPeak && Math.abs(off) < Math.abs(bestOffset));
      if (better) {
        bestPeak = localPeak;
        bestOffset = off;
      }
    }
 
    // Commit the chosen position into the load, then move to the next task
    const finalStart = start + bestOffset;
    for (let m = finalStart; m < finalStart + t.durationMin; m++) base[m]++;
    chosen.set(t.id, bestOffset);
 
    console.log(
      `${t.id}: ${toHHMM(start)} -> ${toHHMM(finalStart)} ` +
        `(${bestOffset >= 0 ? "+" : ""}${bestOffset}min, peak load ${bestPeak})`
    );
  }
 
  return chosen;
}

windowMin is how far you allow a task to move from its original time. I keep it at 90 minutes. Widen it and side effects creep in — an article you wanted out before the morning commute slips into the afternoon. The tie-break that pulls toward the original time is there for the same reason: don't move things more than you have to.

The before / after I actually applied

Against a setup with 2 protected tasks (premium slots) and 4 movable ones, applying the greedy offset gave the following. The evening-skewed starts were flattened with windowMin = 90.

Assuming a 15-minute run time per task, concurrency changed like this.

Max concurrency dropped from 4 jobs to 2, and the premium slots did not move by a single minute. The 20:00 mountain where jobs fought over shared resources is gone, and clones stopped running out of breath afterward. Once you can confirm "the mountain is gone" as a number, the unease from the days of nudging times by gut feel disappears.

Why greedy instead of exhaustive search

Placing tasks is, strictly, a combinatorial optimization — minimizing the peak of interval scheduling — and the closer you get to exhaustive search, the better the solution. I still pick greedy because the goal is not "find the optimal placement" but "stop the fighting." Dropping concurrency from 4 to 2 removes essentially all the operational pain, so there is no reason to pour compute into it. Anything you add to an unattended pipeline is safer the simpler it is, so it doesn't become its own failure source.

There is another point: with greedy, the order in which you move tasks matters. Handle the movable tasks that sit in the busiest windows first, and you tend to reach a flatter solution. Sort the movable tasks by their fire-time congestion in descending order before passing them to staggerOffsets to get that effect.

On the operational side, keeping durationMin close to reality also matters. A generation task that includes clone and build occupies very different time from a light task that only checks logs, so a single flat assumption skews how the peak looks. I pull the median duration from a few runs of logs and put that into durationMin.

Next step

Start by gathering the crons of your own scheduled tasks in one place and running collisionMap to print "the minutes whose value length is 2 or more." That list of tasks firing in the same minute is exactly the collision to fix first. Once you can see it, the line between the slots to protect and the slots you're free to move tends to decide itself.