Keep the Extra Capacity Out of Your Baseline — Burning Backlog During the Time-Boxed +50% Weekly Limit

A burst queue that knows its own expiry

With the sorting done, implementation. The wrong implementation first:

# Before: adding "temporary" entries straight into cron
# Limits went up, so run the integration batch 3x daily (supposedly until 7/13)
0 9,14,21 * * * /usr/local/bin/run-integration-batch.sh

Two problems. First, you will forget to delete it on July 14 — cron entries carry no "this is temporary" metadata, so removal depends on human memory. Second, your logs can no longer distinguish baseline runs from burst runs, which kills the leak detection described below.

Instead, put a queue in front that knows the deadline itself:

// After: an expiry-aware burst queue
// - refuses new jobs once the window has expired
// - rejects jobs whose estimated completion would cross the expiry
// - admits only one-off job kinds via an allowlist
 
type BurstJobKind =
  | "integration-queue"      // drain the integration backlog
  | "link-audit"             // one-shot internal link audit
  | "reference-consistency"; // reference data consistency check
 
interface BurstJob {
  id: string;
  kind: BurstJobKind;
  estimatedMinutes: number; // estimate from past runs of the same kind
}
 
const ALLOWED_KINDS: ReadonlySet<BurstJobKind> = new Set([
  "integration-queue",
  "link-audit",
  "reference-consistency",
]);
 
export class BurstWindow {
  private queue: BurstJob[] = [];
 
  constructor(private readonly expiresAt: Date) {}
 
  /** Admission check at the door. Returning a reason keeps logs readable. */
  admit(job: BurstJob, now: Date = new Date()): { ok: boolean; reason: string } {
    if (now >= this.expiresAt) {
      return { ok: false, reason: "window-expired" };
    }
    if (!ALLOWED_KINDS.has(job.kind)) {
      // recurring job kinds are rejected at runtime, not just at compile time
      return { ok: false, reason: `kind-not-allowed: ${job.kind}` };
    }
    const remainingMinutes =
      (this.expiresAt.getTime() - now.getTime()) / 60_000;
    if (job.estimatedMinutes > remainingMinutes) {
      // Jobs that would straddle the expiry never get in.
      // "Partial progress is still progress" sounds nice, but the cost of
      // cleaning up an interrupted audit usually exceeds the gain.
      return { ok: false, reason: "would-cross-expiry" };
    }
    this.queue.push(job);
    return { ok: true, reason: "admitted" };
  }
 
  /** After expiry, hand leftovers back and empty the queue. */
  drainAfterExpiry(now: Date = new Date()): BurstJob[] {
    if (now < this.expiresAt) return [];
    const leftovers = [...this.queue];
    this.queue = [];
    return leftovers; // caller re-queues these into the normal low-priority lane
  }
}

The point is that admit() is a three-stage gate: the expiry itself, the kind allowlist, and the comparison between estimated duration and remaining time. The third stage is the one people skip. Submit a six-hour audit the day before the deadline and you get a half-finished audit straddling the expiry; without a record of exactly where it stopped, it restarts from zero. Rejecting it at the door is cheaper in total.

Book baseline and burst in separate lanes

Separate queues deserve separate bookkeeping. The goal is the post-expiry inspection: did baseline consumption quietly grow during the window, and did it return to pre-window levels afterward? Only when both check out can you say the borrowed capacity was returned.

// A minimal ledger that tags every run with a lane
type Lane = "baseline" | "burst";
 
interface RunRecord {
  at: Date;
  lane: Lane;
  taskId: string;
}
 
export class LaneLedger {
  private records: RunRecord[] = [];
 
  record(taskId: string, lane: Lane, at: Date = new Date()): void {
    this.records.push({ at, lane, taskId });
  }
 
  /** Run counts per lane over a period */
  countByLane(from: Date, to: Date): Record<Lane, number> {
    const out: Record<Lane, number> = { baseline: 0, burst: 0 };
    for (const r of this.records) {
      if (r.at >= from && r.at < to) out[r.lane] += 1;
    }
    return out;
  }
 
  /**
   * Leak detection: with the pre-window week as 1.00, return the ratio of
   * baseline runs in the target week. Above 1.05, something burst-shaped
   * has leaked into your baseline.
   */
  baselineDriftRatio(refWeek: [Date, Date], targetWeek: [Date, Date]): number {
    const ref = this.countByLane(...refWeek).baseline;
    const target = this.countByLane(...targetWeek).baseline;
    if (ref === 0) return Number.POSITIVE_INFINITY;
    return target / ref;
  }
}

The inspection routine:

1. Record the baseline run count for the week before the window as your 1.00 reference
2. During the window, check daily that the baseline ratio stays under 1.05. If it exceeds that, work that belongs in the burst lane has crept into cron
3. The week after expiry, take the ratio once more and confirm it sits near 1.00
4. Re-queue whatever drainAfterExpiry() returns into the normal low-priority lane. "Wait for the next boost" is not an option I allow myself — there is no guarantee there will be one

I set the threshold at 1.05 because in my environment day-of-week composition (weekly tasks present or absent) naturally moves the number by about ±3%. Measure your own steady-state wobble for a week or two before picking a threshold; I recommend not borrowing mine blindly.

Interim numbers from my setup — day 3 of the window

As I write this it is day 3. As an indie developer running a group of tech blogs on automated schedules, I dropped the machinery above straight into production. Interim figures:

The 1.03 baseline sits inside normal wobble, and burst consumption is using a little under half of the extra 50%. The remaining 17 integration items should clear within the ten days left; the last two link-audit sites, however, have estimatedMinutes estimates that cut close to the deadline, and admit() may well reject them. If it does, they simply return to the normal lane and proceed at the usual pace. The reason a rejection costs nothing is that only work with an end was allowed in to begin with.

A neighboring problem — allocating a non-rollover monthly credit budget across a month — points in the opposite direction: there the goal is to spend it all, here the goal is isolation. I compared the two while writing this and found the contrast useful (see pacing a non-rollover monthly credit budget without starving the month-end).

So that July 14 requires changing nothing

My conclusion on time-boxed limit boosts is short. Don't touch the baseline. Let only finite work in, through a queue that knows the deadline. Book the two lanes separately, and verify with a single ratio that the baseline returned to its old level. Done right, the morning after expiry involves exactly one action: glancing at a ratio.

As a next step, sort your own task list by the single property "does it have an end?" If you find three one-off jobs that qualify, the next ten days make a fine settling-of-accounts period. If you find none, your operation carries no backlog — in which case the extra capacity deserves no attention at all, and that is the healthiest outcome of the lot. I hope this is useful to others running trimmed-down schedules of their own.