How the Gantt Shows a Job Spanning Shifts

A Gantt bar that stretches across shifts and days is EDGEBIC showing you an operation that does not fit in one sitting. The bar's edges are not arbitrary. Its start is the first shift with room for the work, and its end is the shift where the last hour lands. Everything between, including the weekend it appears to leap over, is the operation following the work center's shift calendar. EDGEBIC by User Solutions draws the schedule as bars precisely so a multi-shift job reads as one continuous piece of work rather than a puzzle of fragments.

This post explains what a spanning bar is telling you, why bars skip days, and how the same work can draw short or long depending on shifts and machine instances. For the full picture of reading the Gantt, see the visual scheduling guide.

One Bar Is One Operation

Before reading a spanning bar, fix the unit. On the EDGEBIC Gantt, one bar is one operation: a single routing step of a single job on a single work center. A three-step routing draws three bars, one per step, reading left to right in routing order. That rule holds no matter how long a bar is. A bar spanning three days is still one operation. It has not become three operations because it crossed a weekend.

The bar's horizontal position is where the scheduling engine placed the work. Its length is elapsed calendar time from the operation's start to its finish. That distinction, length as elapsed time rather than work content, is the key to reading spanning bars without being misled.

Why a Bar Skips a Day

The most common question a new user asks is why a bar seems to jump over a day. The answer is almost always the calendar. Bar positions follow the work center's shift calendar. If a machine runs Monday through Friday and an operation starts Friday but cannot finish, it resumes on the next shift the machine actually runs, which is Monday. The bar draws from Friday through to Monday, spanning Saturday and Sunday as a gap, because those days have no shift on that work center.

The same gap appears across a plant holiday or a scheduled downtime day. None of it is the operation pausing for no reason. It is the operation obeying the calendar you built. A bar that "skips a day" is usually skipping a weekend or holiday, which is exactly what a correct schedule should do.

This is worth internalizing because it prevents a false alarm. Planners new to the Gantt sometimes read a weekend-spanning bar as a machine left running unattended. It is not. Add the hours up and you will find the real running time is well short of the span.

Reading Hours Behind the Span

Because a bar's width is elapsed time, you cannot read work content from length alone. A bar stretched over a weekend can carry the same hours as a short bar tucked inside one shift. To read the real work, use two surfaces EDGEBIC gives you.

First, the bar caption. The text on each bar is built from a configurable pattern, and it can include tokens for planned hours, actual hours, remaining hours, and percent complete. Turn those on and the bar tells you its work content directly, independent of how far it stretches. Reading those fields is covered in reading operation description fields on a Gantt bar.

Second, the Job View tab. Its hours roll-up header shows the job's total, actual, and remaining hours plus percent complete, summed from the operations themselves rather than from any single bar's width. That header is where you confirm progress, not by measuring bars with your eye.

How Instances Change the Span

The same operation can draw long or short, and shifts are only half the reason. The other half is machine instances.

When a work center has more than one instance, EDGEBIC can split an operation's hours across them, running the work in parallel. The operation finishes in less calendar time, so its bar is shorter, even though the total hours are unchanged. A 28-hour operation on a single instance might span four working days. The same 28 hours split across two instances can finish in roughly 14 hours of clock time, about two working days, and the bar shrinks to match. The schedule records which instance carried each share, so you can see how the work was distributed.

The lesson is that a bar's length reflects three things at once: the hours, the shift calendar it runs against, and how many instances shared the load. Read all three together and a spanning bar stops being mysterious.

Why Very Short Bars Still Read

A spanning bar is one extreme; the other is an operation so brief it would draw as a sliver too thin to click. EDGEBIC handles that end deliberately. A bar is never allowed to render with a zero or inverted length, because that would break the chart, so a minimum floor is enforced on every bar's span. Very short operations are also widened to a readable threshold so you can grab them, even though the underlying hours are tiny.

The consequence for reading is worth knowing: a small operation may look slightly longer on the chart than its true hours, because it was widened for clickability. This is the mirror image of the spanning-bar lesson. A long bar can hold few hours because it crossed non-working time, and a short bar can look a touch long because it was floored for usability. In both directions, the caption's hours token, not the visual width, is the honest measure of work. When precision matters, read the number.

A Worked Example: The 28-Hour Mill Operation

JOB-2026-0101 has a milling operation needing 28 hours on Mill-Center-1, a work center with a day shift (08:00 to 16:00, 8 hours) and a night shift (00:00 to 08:00, 8 hours). The job is ready to start Monday morning.

With both shifts available and load balancing across two instances, the engine fills the shifts in order. Monday's day shift takes 12 hours of headroom across the two instances, then the following shifts take the rest, and the operation completes on Tuesday afternoon. The bar draws as one continuous piece from Monday morning to Tuesday, roughly a day and a quarter of elapsed time, even though it holds 28 hours of machining, because two instances ran the hours in parallel across day and night shifts.

Now change one thing: the night shift is dropped for a maintenance window. The same 28 hours must fit into day shifts only. The bar stretches further, and if a weekend falls in the middle, it spans that too. Nothing about the operation changed except the calendar it had to run against, and the bar's new length shows it. Read the caption's planned-hours token and it still says 28. The span grew; the work did not.

This is the discipline in one line: length is elapsed time, hours are work, and the calendar sits between them. It is the same reasoning that underpins finite capacity scheduling, where a machine can only do so much per shift, so long jobs necessarily spread across days.

Why This Reads Better Than a List

A dispatch list can tell you an operation needs 28 hours. It cannot show you that those 28 hours land across two shifts, skip a weekend, and finish Tuesday. The Gantt shows all of that in a single bar, and it shows it for every operation at once, so you can see where a long job collides with a machine that is already busy. User Solutions has been drawing schedules this way for manufacturers since 1991, for shops of every size and for names like GE and the US Navy, because a bar that spans shifts tells a planner more in one glance than a row of numbers tells in a page.

Reading spanning bars is a small skill with a large payoff: you stop misreading elapsed time as work, and you start seeing the calendar the schedule actually runs against. Bring your shift calendars to a demo and watch a real job spread across them. Give US a chance to show you the whole span.