Skip to content

Network Capacity Dashboard

Monitoring dashboard — instantiates Internal Capacity Deepening

A live topological view of a flow network that shows where capacity is saturated, where it sits idle, and where the binding bottleneck has moved.

Before anyone can decide whether to densify or expand, they have to see that internal capacity is uneven — that local overload and idle capacity coexist. Network Capacity Dashboard is the sensing layer that makes that visible. It maps utilization across the topology of a flow network — nodes, paths, and the queues between them — rather than reporting one aggregate number, so it exposes the archetype's central fact: a system can be jammed in one place and half-empty in another at the same instant. Its defining move is that it watches the constraint move: relieve one hot spot and the dashboard shows load piling up at the next one. That is what separates it from a single-capability health monitor — it is a map of where, across a network, capacity is tight, slack, or shifting.

Example

A container terminal runs berths, quay cranes, a yard of stacking blocks, and a truck gate. On a busy morning the dashboard shows the gate queue swelling past forty minutes while three yard blocks sit under 50% full — the terminal is not out of capacity, it is misaligned. Operations opens more gate appointment slots, and within a shift the dashboard shows the queue drain and a new red band appear at the quay cranes: the binding constraint has migrated from the gate to the cranes. No new asset was bought; the dashboard simply revealed that the "shortage" was a distribution problem and then tracked where relieving it pushed the load next.

How it works

  • Model the topology, not a total. Capacity and load are shown per node and per path, so saturation and slack are visible side by side instead of averaged into one figure that hides both.
  • Read against effective capacity. Each node's reference line is its realistic throughput net of setup, failures, and mix — not nameplate — so utilization means something.
  • Track the moving constraint. The dashboard highlights the currently binding node and flags when relief shifts the bottleneck elsewhere, so attention follows the constraint rather than yesterday's hot spot.

Tuning parameters

  • Topological granularity — nodes only, or paths and segments too. Finer resolution locates misalignment precisely but multiplies the tiles to watch and the data to maintain.
  • Refresh latency — real-time versus end-of-day. Real-time catches transient jams and queue buildup; slower refresh is cheaper and less noisy but blind to bursts.
  • Saturation thresholds — where "hot" and "cold" are drawn. Tight thresholds surface misalignment early but cry wolf; loose ones miss it until it bites.
  • Effective-vs-nameplate reference — how much derating is baked into the ceiling each node is measured against. Honest derating prevents false "we still have room" readings.
  • Trend horizon — an instantaneous snapshot or a queue-buildup trend. Trends catch a constraint forming before it saturates.

When it helps, and when it misleads

Its strength is showing overload and idle capacity together, which is exactly the internal yield the archetype wants harvested before any footprint is added — and catching the bottleneck's migration so relief is aimed at the node that binds now.

Its failure modes are the classic ones for an instrument. Teams start managing to the dashboard — optimizing the green tiles rather than the flow, the moment a displayed metric becomes the target.[1] Averaging across a path can also paint a corridor green while one segment inside it is saturated, and a dashboard shows symptoms, never causes: it says the cranes are the constraint, not why. The discipline that keeps it honest is to instrument effective (not nameplate) capacity, read at the resolution where misalignment actually lives, and always chase the constraint that is moving rather than the one that was pinned last quarter.

How it implements the components

  • effective_capacity_baseline — establishes each node's and path's realistic throughput ceiling net of setup, failure, and product mix; the reference every utilization reading is measured against.
  • overload_and_underutilization_monitoring — its core signal: it flags saturated nodes and idle ones in the same view, exposing the misalignment the archetype exploits.
  • constraint_migration_monitor — tracks the binding bottleneck as relieving one point pushes load to the next, so the constraint is followed, not lost.

It does not track a single consolidated capability's unit cost, quality, or service-level adherence (utilization_ceiling, quality_consistency_guardrail, service_level_or_performance_target) — that's Capacity Utilization Dashboard; nor take the point-in-time inventory of idle internal positions (internal_position_inventory) — that's Occupancy and Idle-Capacity Audit.

Notes

The dashboard is descriptive, not prescriptive: it shows where capacity is tight or slack, never whether the slack is worth harvesting or the constraint worth relieving. That judgement belongs downstream to Marginal Capacity Value Review and Capacity Investment Analysis, which consume its picture. Keeping sensing separate from decision is what lets the map be trusted as evidence rather than argued with as a verdict.

References

[1] Goodhart's Law — when a measure becomes a target, it ceases to be a good measure. Dashboards are especially prone to it because the displayed tile is so easy to optimize directly; the guard is to watch flow outcomes, not just the indicator. ↩