Private Fleets are dedicated game server hosting on capacity reserved for your studio: fixed hardware, no egress fees, servers that can stay up 24/7 without a cost penalty for idling. The Utilization view tells you whether that reserved capacity is earning its keep.

This article answers two questions. What does each part of the chart mean, and why does it sometimes show idle capacity and cloud overflow in the same hour?

The Axis: Your Fleet Below, Public Cloud Above

The zero line splits the view. Below it is your fleet. Above it is public cloud.

The orange line marks total vCPU available in your fleet, and the space between the axis and that line is broken into two shades:

• Solid green is vCPU actually used by deployments.

• Pale green is idle vCPU, capacity you own and did not use that hour.

Above the axis, a violet bar shows total vCPU of deployments that overflowed to public cloud after your fleet capacity was exhausted. Violet is not a failure state. It is the safety valve working, and it is the clearest signal you have that your fleet is undersized for that hour in that city.

Each city gets its own chart, covering every host you have in that city in the current fleet. Each bar is one hour, timestamped in UTC. You can view the last 7 days or the last 30 days.

One deliberate omission: the most recent three hours are not shown. Deployments that end up in an Error state take time to settle, and including them would report usage that never really happened.

One Fleet, One Location

A Private Fleet is reserved capacity in a place you chose. That is the whole premise, and it is also the constraint that makes this chart worth reading.

Because the hardware is yours and egress is not metered, the per-hour cost of a fleet server is fixed and low, and it does not go up when a match runs long or a lobby sits idle between rounds. Always-on is cheap. Scaling out is not, because you cannot conjure a new host in Frankfurt when the demand showed up in São Paulo.

So the tradeoff is location, not just volume. Players near your fleet get your best cost per server and your best latency. Everyone else gets covered by cloud overflow at cloud prices. The Utilization chart is where you see how that split is actually landing, city by city, hour by hour.

Every Bar Is an Average, Not a Peak

This is the single most important thing to internalize before you draw conclusions from the shape of the chart. Values are the average over 60 minutes. Deployments are counted by the share of the hour they actually ran.

• 4 vCPU x (60 min uptime / 60 min) = 4 vCPU

• 4 vCPU x (30 min uptime / 60 min) = 2 vCPU

• 4 vCPU x (15 min uptime / 60 min) = 1 vCPU

Same peak, three different bars. For session-based games where a match lasts eight minutes and a lobby churns constantly, the hourly average will always read lower than the load your hosts genuinely handled. Short bursts flatten out.

That does not make the number wrong. It makes it a capacity-planning number rather than a real-time monitoring number. Use it to answer "how much of my fleet earns its keep over a week," not "how hot did my host get at 14:07."

Small Deployments Can Disappear

A single 0.25 vCPU deployment running for 6 minutes counts as 0.03 vCPU over the hour. Against a 12 vCPU fleet, that is roughly 0.25% of total capacity. At chart scale, it is a bar you cannot see.

So a fleet that served a handful of small test deployments can render as flat idle. This is not a bug.

Two ways to confirm what actually ran: hover any bar to read the exact Cloud, Fleet used, Idle and Total capacity values, or open the deployment list to review deployments directly. The tooltip is the source of truth. The bar height is a summary.

Short Bursts Can Look Like Idle Capacity

Here is the combination that generates the most support tickets. Deployments fully saturate your fleet, overflow to cloud, and the same hour still reports a large block of idle capacity.

Consider an hour with 100% fleet usage for 12 minutes and 6 vCPU overflowing to cloud, followed by 3.25 vCPU of fleet usage for the remaining 48 minutes. Averaged across the full hour, the chart reports 5 vCPU used, 7 vCPU idle, and 1.2 vCPU of overflow.

Every one of those numbers is correct. None of them describes what happened at minute six.

When you see violet and a wide pale green band together, read it as a burst-shaped workload rather than a contradiction. Your fleet was full, briefly. The fix is not a bigger average, it is more headroom at the peak. Edgegap's orchestration handles that overflow automatically, deploying to public capacity in an average of 3 seconds when your own hosts are exhausted (how that cold start works).

Overflow With Idle Capacity Still Showing

The idle value sums the idle capacity of every host in a city. Deployments do not get to sum anything. A deployment lands on one host, whole.

Take three hosts with 4 vCPU each, running 3 vCPU of deployments apiece. The chart reports 3 vCPU idle in that city. No single host has more than 1 vCPU free, so a new 1.5 vCPU deployment cannot be placed anywhere and goes to cloud. A deployment asking for 1 vCPU or less would have fit.

Fragmentation, not arithmetic. If you see steady overflow against a persistent idle band, check your deployment's vCPU request against your per-host capacity before adding hosts. Fewer, larger hosts fragment less than many small ones for the same total vCPU.

What to Actually Do With the View

Read the 30-day view for sizing and the 7-day view for behavior.

• Deep pale green all month: your fleet is larger than your demand in that city. Cost is going somewhere it is not needed.

• Violet at the same hours every day: a predictable peak. That is the case for buying more hardware in that location.

• Violet scattered at random: a burst profile. Overflow is doing its job, and more owned hardware would mostly sit idle.

The chart does not tell you which of those to pick. It does tell you which one you are in, and that is the part most teams are guessing at.

Private Fleets or Public Cloud?

It depends, really, based on your use case and your game. The reason overflow exists is that the two answer different problems.

Public cloud capacity through Edgegap's orchestration reaches 615+ locations and boots a server in roughly 3 seconds wherever the players are, at a single price for every location. You pay for what you use, and you pay egress.

Private Fleets invert that. One location, capacity you already hold, no egress, and a cost that does not scale with playtime. Cheaper per server for load you can predict, useless for load you cannot place.

Studios with a concentrated playerbase and steady traffic run the base load on a fleet and let overflow catch the rest. Studios with players spread thin skip the fleet entirely. The chart tells you which studio you are.