When the Batch Window Shrinks

Nobody has ever called a meeting to shrink the batch window. There is no ticket for it, no change record, no owner. It happens the way coastlines erode. Claim volumes drift up a few percent a quarter, two new feeds join the night, and the finance team starts reading reports an hour earlier. The chain used to finish at 03:40 with hours to spare. Now it slides in at 05:10 against a 05:30 deadline, every single night, with nobody able to say when the margin went. Then one ordinary Tuesday a partner file is twenty minutes late, and there is no slack left to absorb it. The margin did not announce it was leaving. It went a few minutes a month and assumed nobody was counting.

This article is about seeing that erosion before the Tuesday, and about what to do once you have seen it. You will learn how to measure your runway, the real, trending distance between where the night finishes and where it must. You will learn how to find out where the hours actually go. We will cover which quick wins buy time back and in what order of effort. We will also cover how to recognize the honest point where no quick win is left and the architecture itself has to change. This article is part of our Nightly Batch Ecosystems series. It uses the worked night of The Anatomy of a Batch Night: Harborview Mutual, whose ten-hour night we mapped from the 19:30 close to the 05:30 print deadline.

Why Windows Shrink

A batch window is squeezed from three directions at once, which is why the shrinkage feels mysterious — no single cause is ever big enough to blame:

• The work in the middle swells. Business growth arrives as data volume, and the long jobs of the night rarely scale linearly with it. A run that grew 8% in volume can grow 15% in duration once it starts spilling past memory, index, or I/O comfort zones. More partners and more products also mean more feeds, each adding minutes and one more thing to wait for.
• The evening end moves later. The night cannot start until the day's data is complete — and the business day keeps lengthening. Extended trading hours, customers in more timezones, online activity that never quite stops: each pushes the end-of-day close later, delaying the whole chain's start.
• The morning end moves earlier. Executives want numbers at 07:00 instead of 08:30; a new downstream system needs its feed by 05:00; a vendor tightens its presort deadline. Every such change trims the far end of the window, usually without anyone consulting the people who run the night.

Two amplifiers make the squeeze lumpy rather than smooth. Calendar cycles concentrate growth: month-end and quarter-end nights carry double volumes plus extra feeds. So the window that still fits on an ordinary Tuesday overflows on the 1st. That is why the first missed deadline is almost always a month-end. And every incident borrows from the same margin: a retry loop, a resent partner file, a catch-up replay all spend window minutes. So a shrinking window makes ordinary hiccups more expensive at exactly the rate it makes them harder to absorb. The calendar never negotiates, and it always knows what day it is.

The result is a fixed-length corridor with a growing train in it. The distance between the train's nose and the corridor's end — between the chain's typical finish and the first hard deadline — is your runway. Unlike the causes, the runway itself is measurable to the minute.

Measuring Your Runway

Runway measurement needs three timestamps per night and the discipline to keep collecting them for months, because the signal is the trend, not any single night:

1. Chain start — the first meaningful event of the night (Harborview: the 19:30 close, or the moment the day's extract lands).
2. Chain finish — the completion of the last critical-path step (Harborview: the print file confirmed sent).
3. Window end — the first hard deadline (05:30). This one only changes when the business changes it.

Runway is window end minus chain finish. Collect it nightly from records you already have — scheduler history, job logs, and the transfer server's activity log. The activity log timestamps the outbound sends that usually mark a chain's true finish. If your transfer server logs to a database, as Sysax Multi Server can, the whole history is a query. It gives you the nightly send time of print_YYYYMMDD.zip over the last year, one row per night, ready to chart. Then summarize per month, and per month-end separately. Month-end nights are their own species, and averaging them into the rest hides exactly the nights that will hurt you. A minimal tracking sheet:

RUNWAY LOG — chain start and finish vs 05:30 deadline (per month)

month        p50 start   p50 finish   p90 finish   month-end   runway @ p90
9 mo ago     19:36       03:52        04:18        04:36       1h12
6 mo ago     19:41       04:05        04:31        04:58       0h59
3 mo ago     19:48       04:16        04:44        05:15       0h46
this month   19:55       04:24        04:57        05:21       0h33

start drift:  ~ -2 min/month (close keeps slipping later)
finish drift: ~ -5 min/month at p90  =>  runway exhausted in ~6 months
month-end already inside 10 min of the deadline

Three conventions make the log honest. Track the p90 finish (the time your slowest one-night-in-ten beats), not just the average. Deadlines are missed by bad nights, and the p90 is your bad-night forecast. Track the start as well as the finish, because the two drifts have different causes and different cures. Harborview is losing five minutes a month at the finish line, but two of them arrive at the start. The business day's close keeps slipping later, and no amount of job tuning fixes an input that begins late. And record the drift rate for both ends. Runway divided by net drift is the most important number in this article. It is the countdown clock to the first missed deadline on a night when nothing even went wrong. I have watched ninety minutes of runway become ten without a single incident in between; the drift rate was the only warning anyone got.

More than one hard deadline may live in your morning — a 05:00 downstream feed and a 05:30 print run. In that case, keep a runway figure per deadline, each measured from the completion of its own chain. The binding one is whichever countdown is shortest, and it is not always the famous one. A minor feed with a tight deadline and a slack-free branch can be the real edge of your corridor. The famous deadline gets the meetings. The quiet one gets the miss.

The picture below shows Harborview's squeeze: the corridor stays 19:30 to 05:30 while the chain inside it grows, and the month-end p90 has already crossed the line.

Where the Hours Actually Go

Before buying time, find out who is spending it. Extend the runway log downward: per-step durations for every node on the critical path, trended the same way. (Off-path steps can grow all they like until they capture the path — worth a glance, not a vigil. The mechanics of paths and slack are in Mapping Batch Dependencies.) In practice the hours hide in four places:

• One or two swelling jobs. Usually the core run — Harborview's adjudication — growing faster than volume. This is where measurement prevents waste: if adjudication is eating four of your five lost monthly minutes, tuning anything else is theater.
• Dead air between steps. Clock-scheduled chains are full of padding. Consider the job that finishes at 02:08 while its successor waits for a 02:25 start time someone chose to be safe. Fifteen minutes here, ten there — many nights carry 45–90 minutes of pure waiting, invisible because no job is "slow."
• Serialized work that could overlap. Three partner downloads running one after another; the warehouse load waiting for the letter build it shares nothing with. The dependency map tells you exactly what may overlap: anything not connected by an edge.
• Squatters in the window. Work that runs at night purely out of habit — archive sweeps, report distribution, housekeeping — consuming critical-path minutes for tasks with no morning deadline at all.

Harborview's diagnosis, from one month of per-step numbers, is typical of what this exercise turns up. Adjudication has grown from 1h40 to 2h10 across four quarters — three of the five lost monthly minutes live there. The three partner claim pulls run one after another at 23:00, forty-one minutes serialized where the longest single pull is sixteen. There are twenty-two minutes of dead air across four clock-scheduled handoffs. And an archive sweep occupies 02:30–02:55 on the same storage the warehouse load hammers, slowing a critical step to save minutes nobody needs before noon. None of these facts was known before the measurement; all four became tickets the same week. The archive sweep, asked to justify its slot, had no deadline and no defenders.

The Quick Wins, Ranked by Effort

The menu below is ordered by effort-to-payoff, which is rarely the order people try them in. The instinct is to buy hardware first, when the cheapest hour is usually hiding in the schedule itself:

The top rows deserve a word each. Dead air disappears when handoffs become event-driven instead of clock-guessed: the next step fires when its input actually exists. On the transfer layer this is a solved problem. Sysax FTP Automation's folder monitoring can launch a transfer task the moment a producing job drops its output. This closes the 02:08-to-02:25 gap to seconds. The general pattern, with its arrival-safety caveats, is introduced in event-driven transfers.

Earlier staging exploits the quietest hours of the night. Partner files that trickle in from 21:00 onward can be collected, decompressed, validated, and staged as they arrive. Then the 23:00 cutoff moment triggers pure processing instead of a scramble of fetching and checking. The same thinking moves outbound prep earlier: anything assemblable before the final numbers exist should be. Parallelism is the biggest single lever for transfer-heavy stretches. Three partner pulls that serialize into forty minutes finish in sixteen when run side by side. The Enterprise edition of Sysax FTP Automation runs scheduled tasks in parallel for exactly this reason. But respect the caveat column: parallel transfers share bandwidth, disks, and the receiving server. The map's resource dependencies decide how much overlap is real. For the long-haul links, compression in transfer pipelines covers when shrinking bytes buys minutes and when it just buys CPU heat.

Whatever you pick, apply the changes with laboratory manners. Make one move at a time, take a week of runway measurements after each, and record before and after in the log. Batch nights are noisy systems — volumes swing, partners wobble. Two changes landed together mean you will never know which one bought the forty minutes, or which one caused the new 02:00 slowdown. The measurement habit you built for the runway is the same instrument that scores the fixes. It is also, conveniently, the evidence that wins the budget conversation when the cheap moves run out. I have lost credit for a forty-minute win that way, to an unrelated change that landed the same night. Batch nights generate enough mysteries without help.

Kestrel Payroll's runway log earned its keep the first time they overlapped anything. They parallelized three bureau downloads, and the pulls dropped from thirty-eight minutes to fourteen, which the log recorded the first night. It also recorded, over the following week, that the payroll calculation had slowed by thirty minutes. That was because the staging folder and the calculation's scratch space shared one disk that was now being hammered from three directions at once. Net result: a loss of six minutes and a very tidy chart. The downloads moved to a separate volume the week after, and the thirty minutes came back. The change log gained a standing note to check the map's resource edges before overlapping anything.

The Honest Point Where Architecture Must Change

Every move in the table is a one-time purchase, and growth is a subscription. Squeeze out ninety minutes and five percent quarterly volume growth takes it back in a couple of years — faster if the core job scales badly. So the shrinking window has an endgame, and its signs are unambiguous. The month-end p90 crosses the deadline (you are now missing deadlines on normal bad-luck nights). The quick-win list is exhausted and drift continues. Recovery has become impossible because a single retry blows the margin. This quietly breaks the catch-up playbook from earlier in this series, since replay time no longer exists. Growth does not read the change log.

At that point there are only two honest directions. Note that "add an operator to babysit the night" is neither, because human heroics scale worse than any job and burn out faster than any disk:

• Renegotiate the corridor. Some deadlines are physics; others are fossils. Re-derive them the way the cutoffs article prescribes. You may find the 07:30 report deadline is a habit nobody would defend. Or you may find a vendor offers a later presort for a fee smaller than a re-platforming project. Cheapest architecture change available: moving a wall that turns out to be a curtain.
• Shrink the batch, not the night. The durable fix is moving work out of the window entirely. Feeds flow and validate on arrival all evening. Increments are processed as they land instead of one mountain at midnight. Daytime-capable steps run in daylight. The night keeps only what genuinely needs the day's complete data. That transformation — done incrementally, without betting payroll on a big bang — is the whole subject of the next article, Modernizing a Batch Ecosystem. (And if what is outgrowing the night is sheer data volume — datasets measured in terabytes — the toolbox changes again; see our moving massive datasets series.)

Erosion Is a Number Now

The shrinking window stops being an anxiety the day it becomes a chart. Start and finish are trended by month, p90 and month-end tracked separately, drift rate computed, countdown known. A one-line summary belongs in whatever report your team already reads. "Runway 33 minutes, losing five a month" fits in a status email and lands harder than any incident retrospective. Erosion has finally been invited to a meeting. From there the sequence is mechanical. Find where the hours go, spend the quick wins from cheapest to dearest, and watch the drift rate. Watch for the honest point where the architecture conversation is due before the first missed deadline forces it in a war room. The night sheet from The Anatomy of a Batch Night gives you the chain to measure. Modernizing a Batch Ecosystem shows what to do when the countdown says the corridor has to change.

Frequently Asked Questions