gantt
The phrase turns up in a status meeting, usually from whoever is being asked why a date cannot move. Something is described as being on the critical path, everyone nods, and the meeting continues without anyone stating which tasks those are or how that was worked out. The term has a precise meaning, it is easy to check on a small plan, and most of the confusion around it comes from three or four specific misreadings rather than from the definition itself.
This is the plain version. What the words cover, a worked example small enough to verify with a pen, the neighbouring terms that get used interchangeably and should not be, and the conditions under which the whole idea stops being worth calculating.
The critical path is the longest chain of dependent tasks through a project, measured in elapsed time. Because that chain is the longest one, its total duration is also the shortest time the project can possibly take. Every task on it has zero slack, so a one day slip on any of them pushes the finish date by one day.
Two words in that sentence carry the weight. Dependent means the tasks have to happen in order, because one cannot start until another has finished. Work that merely happens at the same time as other work is not a chain. Elapsed means calendar time rather than effort. A task that takes four hours of work but has to wait five days for an external approval occupies five days on the path.
Everything else follows. Tasks not on that longest chain have float, which is the number of days they can slip before they start moving the end date. A plan with a known critical path therefore splits work into two groups that deserve different treatment: a small set where any delay is immediately a schedule problem, and a larger set where delay is absorbed until the float runs out.
The word critical is the part that misleads. It has nothing to do with importance, difficulty, cost, risk or who is watching. A trivial task nobody thinks about can sit on the critical path, and the most expensive piece of work in the project can sit off it with a week of float. The term describes a position in the network of dependencies, and nothing else.
Take a site relaunch with seven pieces of work. Durations are in working days and each task lists what has to finish before it can start.
| Task | Duration | Cannot start until |
|---|---|---|
| A. Sign off the content plan | 2 days | nothing |
| B. Write the copy | 8 days | A |
| C. Design the page templates | 5 days | A |
| D. Build the templates | 6 days | C |
| E. Load the copy into the build | 2 days | B and D |
| F. Legal review of the copy | 3 days | B |
| G. Launch | 1 day | E and F |
There are three routes from start to finish. Add up each one.
The longest route is 16 days, so the critical path is A, C, D, E, G, and the project cannot be done in less than 16 working days while those dependencies hold.
Now look at what that tells you about the two tasks that are not on it. Writing the copy takes 8 days, which makes it the single longest task in the project, and it has float. The copy can finish 2 days late without moving the launch, because the build chain through C and D is what the launch is actually waiting on. The longest task and the critical task are different things, and mistaking one for the other is the most expensive error in this whole subject. Pushing the writers to compress an 8 day task buys nothing at all. A 2 day slip on the template build, which is a mid sized task nobody was watching, moves the launch date.
The second thing worth noticing is that B and F share their float. The chain of B then F has 2 days of slack between them, not 2 days each. If the copy runs 2 days late, the legal review has none left, and the moment it runs into a third day the critical path changes shape and now runs through B and F instead. The path is a property of the current numbers, not a permanent label. Recalculating it after every real change is not housekeeping, it is the entire method.
One more thing falls out of the example, and it is the part that matters on a real board. The critical path is not drawn by colouring in the tasks that look important. It is produced by the dependency arrows, which means a plan without recorded dependencies has no critical path at all, only a set of bars that happen to sit next to each other. Two teams can hold the same seven tasks with the same seven durations and get different finish dates purely because they disagree about which pieces of work block which. That disagreement is usually worth more than the calculation, because it surfaces assumptions that nobody had written down.
Four terms get used as though they were synonyms in status meetings. They describe different things, and mixing them up leads to the wrong task being pushed.
| Term | What it identifies | What it is driven by |
|---|---|---|
| Critical path | The chain of tasks whose total length sets the finish date | Dependencies and durations |
| Bottleneck | The resource or step with the least capacity, where work queues up | Capacity and throughput |
| Longest task | The single task with the largest duration | Nothing in particular |
| Float | How far a task can slip before the finish date moves | Its position relative to the critical path |
The bottleneck confusion is the common one, because both words describe something that constrains an outcome. A bottleneck is about capacity over time. One reviewer for twelve documents is a bottleneck whether or not any of those documents is on the critical path. The critical path is about ordering in a single plan. Adding a second reviewer fixes a bottleneck. It only shortens the critical path if the review sits on the longest chain.
Float is where the two ideas touch. Once the critical path is known, float is the same calculation run for everything else, and it is the number that actually gets used day to day. Nobody needs to be told that a critical task is late. The useful question is how many days of slack are left on the tasks that are not critical, because that is where a problem is still fixable quietly.
Knowing which chain holds the date changes three concrete decisions.
If a task has 6 days of float, it can survive being handed to someone who is learning. A zero float task cannot. Deliberate assignment by float is one of the few uses of this calculation that pays off within a single project, and it costs nothing to apply.
On a flat task list every delay reads the same, so either everything gets escalated or nothing does. With float in view, a task that is 3 days late with 8 days of slack is a note, and a task that is half a day late with none is a phone call. The same information produces two different reactions, correctly.
Requests to pull a date in are usually answered by asking everyone to go faster. The only work that can shorten a project is work on the critical path, through either shortening a task on it or removing a dependency so two tasks can overlap. Cutting 3 days from a task with float changes the finish date by zero days. This is the part of the method that survives contact with the real world most reliably, because it stops a compression exercise from spraying pressure across a whole team.
The calculation assumes three things that are true on some projects and not on others. It is worth checking which kind of project is in front of you before buying software to compute it.
It assumes the dependencies are real. A network where most arrows mean "roughly after the design is agreed" rather than "physically cannot start until this exists" will produce a float column that is precise and meaningless. Twenty tasks with honest dependencies beat two hundred with invented ones.
It assumes the durations are estimates of elapsed time, including waiting. Teams that estimate effort and then let the plan imply the calendar get a critical path that is shorter than reality, because review queues, client approvals and procurement never appear in it.
It assumes tasks without a dependency between them can run in parallel. That stops being true the moment they are assigned to the same person. On a team of five, people are the real constraint most of the time, and the standard calculation knows nothing about that. Resource levelling is a separate step, and a plan that has never had one often contains dates nobody could physically work.
Where the calculation does hold, the practical refinement is to stop treating zero float as the only line that matters. A task with 1 day of slack behaves almost exactly like a critical task, because a single bad afternoon consumes it. Teams that review everything under about five days of float catch problems while they are still cheap, whereas teams that watch only the zero float list get surprised each time a near critical chain tips over. The threshold depends on how often the plan is updated: a schedule reviewed weekly needs a wider margin than one updated daily, simply because a week can pass before anyone notices the slack is gone.
There is also a plain volume threshold. Below roughly twenty tasks the longest chain is usually visible by reading the plan, and the formal calculation adds ceremony rather than information. Above a hundred tasks with contractual milestones, doing it by hand stops being possible and the software earns its cost.
Most tools that draw a timeline will not calculate a critical path, and the ones that do usually put it behind a specific plan. Two published examples, checked on 26 September 2026: GanttPRO lists auto scheduling on its Core plan at $7 per user per month billed annually, and TeamGantt includes critical path scheduling on its Base plan at $59 per month flat for 1 manager and 10 collaborators. The pricing models differ enough that a team of twelve should do the arithmetic both ways before choosing.
The more useful question for a small team is whether the dependency data exists at all. A computed critical path on a plan that one person maintains in isolation tells you about that person's mental model, not about the project. Where the timeline sits on the same cards the team already updates, the chain is at least drawn from current information, which is the only version worth acting on. The comparison pages set out which tools include a timeline view from the start and which put it on a paid tier, and the feature list covers how a Gantt view and a kanban board can hold the same cards rather than two separate copies of the plan.
Write the dependency list for the project currently in flight, by hand, before evaluating any software. Twenty tasks and one arrow for each pair where the second genuinely cannot start until the first has finished. If that produces a long chain with real constraints, the calculation is worth automating, and putting the timeline on the same board the team already updates is where Pinateca fits. If it produces four short chains and a pile of independent work, the finish date was never being set by a path.
It means that task sits on the longest chain of dependent work in the plan, so it has no slack. If it finishes a day late, the whole project finishes a day late unless something else is changed. It does not mean the task is the most important, the most difficult or the most expensive, which is why the phrase causes so much confusion in status meetings.
Yes, and it happens more often than people expect. Whenever two chains of work come out at the same total duration, both have zero float and both control the finish date. It also happens over time, since a chain with 2 days of float that slips by 3 days becomes critical. Reviewing every path with less than about a week of float is safer than watching only the zero float one.
No. A bottleneck is a capacity problem, such as one reviewer handling work for twelve people, and it exists regardless of the plan's structure. The critical path is an ordering property of one plan's dependencies and durations. Adding capacity fixes a bottleneck, and it only shortens the project if that step happens to sit on the critical path.
List every task with its duration and what has to finish first, then trace each route from start to finish and add up the durations. The longest route is the critical path. This is entirely practical up to twenty or thirty tasks, and the reason it stops scaling is not the arithmetic but the need to redo it every time an estimate changes.
Constantly, and that is the point most often missed. The path is calculated from the current durations and dependencies, so every actual start date, every revised estimate and every new dependency can move it. A critical path worked out once at kickoff and never revisited describes a plan that no longer exists.