The queueing theory calculator above solves the two standard Markovian queue models. M/M/1 describes a single server with one waiting line. M/M/c describes several identical servers drawing from one shared line, the arrangement used at bank counters, airport security and call centres. From an arrival rate, a service rate and a server count it returns utilisation, the average number in the queue and in the system, the average wait, and the probability that an arriving customer finds every server busy and has to wait at all.
Arb Digital publishes this page because the central result is so counter-intuitive that it changes decisions. Waiting time does not rise smoothly with load. It rises hyperbolically, and near full utilisation it explodes. A system running at 90 per cent of capacity has more than twice the queue of one at 80 per cent, and one at 99 per cent has more than twelve times the queue of the 90 per cent system. Any plan that involves running a service at "close to full capacity for efficiency" is a plan to produce enormous queues, and the arithmetic on this page shows exactly how enormous.
What This Queueing Theory Calculator Does
It computes the steady-state performance measures for a queue with Poisson arrivals, exponentially distributed service times, c identical servers, one shared first-come-first-served line, and no limit on how many customers may wait. Those five conditions are what the shorthand M/M/c means, and they are stated plainly here because every number below depends on them.
The outputs are the standard set. Utilisation ρ is the fraction of time a server is busy. L is the average number of customers in the system, Lq the average number waiting rather than being served. W is the average time a customer spends from arrival to departure, Wq the portion of that spent queueing. The probability of waiting is the Erlang C figure, which is what workforce planners in contact centres actually size against. Steady state means these are long-run averages once the system has settled; they do not describe a lunchtime rush that lasts twenty minutes and then stops.
How to Use It
- Measure the arrival rate. Count arrivals over a period when demand is roughly stable and divide by the hours. Do not average across a quiet night and a busy afternoon — the model assumes one steady rate.
- Convert service time into a rate. If a transaction takes 6 minutes on average, one server handles 60 ÷ 6 = 10 per hour. That is μ.
- Set the number of servers. This is the count feeding a single shared queue. Separate queues per server is a different, worse system.
- Check that ρ is below 1. If arrivals exceed total service capacity, no steady state exists and the queue grows without limit. The tool says so instead of returning a number.
- Compare Wq across server counts. Adding one server at high utilisation often cuts the wait by an order of magnitude, which is the practical use of the model.
The Formulas and How It's Calculated
Write a = λ ÷ μ for the offered load in erlangs, and ρ = a ÷ c for utilisation per server. For M/M/1 the results are compact: L = ρ ÷ (1 − ρ), Lq = ρ² ÷ (1 − ρ), W = 1 ÷ (μ − λ) and Wq = ρ ÷ (μ − λ). The probability the system is empty is 1 − ρ, and the probability an arrival must wait is ρ itself.
Take the defaults: eight arrivals per hour against a service rate of ten per hour with one server. Utilisation is 0.8. The average number in the system is 0.8 ÷ 0.2 = 4 customers, of whom 0.64 ÷ 0.2 = 3.2 are waiting. Average time in the system is 1 ÷ (10 − 8) = 0.5 hours, or 30 minutes, of which 0.8 ÷ 2 = 0.4 hours, or 24 minutes, is spent queueing and 6 minutes is the service itself. An arriving customer finds the server busy 80 per cent of the time.
For c servers the empty-system probability P₀ is the reciprocal of the sum of aⁿ ÷ n! from n = 0 to c − 1 plus ac ÷ (c!(1 − ρ)). The Erlang C probability of waiting is ac ÷ (c!(1 − ρ)) multiplied by P₀, and then Lq = Pwait × ρ ÷ (1 − ρ), with Wq = Lq ÷ λ and W = Wq + 1 ÷ μ. Setting c = 1 collapses every one of these back to the M/M/1 expressions, which is a useful check that the implementation is right. MIT OpenCourseWare's Logistical and Transportation Planning Methods derives these from the underlying birth-and-death process.
What Happens as Utilisation Approaches One
Every formula above has (1 − ρ) in a denominator, and that is not a coincidence — it is the structure of the answer. As ρ climbs toward 1, that denominator shrinks toward zero and the queue length and waiting time grow without bound. The growth is not gradual. Holding the default single-server system fixed and varying only the arrival rate, the average queue length Lq runs: 0.11 customers at 25 per cent utilisation, 0.5 at 50 per cent, 3.2 at 80 per cent, 8.1 at 90 per cent, 18.05 at 95 per cent and 98.01 at 99 per cent.
Read those numbers as a sequence rather than individually. Going from 50 to 80 per cent utilisation, a large change in load, multiplies the queue by six. Going from 90 to 99 per cent, a much smaller change in load, multiplies it by twelve. The last few percentage points of capacity are extraordinarily expensive in waiting time, and they are exactly the points a manager optimising for utilisation will try to claim. This is why service systems are deliberately run with slack, and why the slack is not waste.
The mechanism is randomness, not arithmetic sleight of hand. If arrivals were perfectly regular and service times identical, a system at 99 per cent utilisation would have no queue at all. Queues form because arrivals bunch up and some jobs take longer than others, and at high utilisation the system has no idle time in which to recover from a bunch. Variability plus high utilisation produces the queue; remove either one and it collapses. That is also why reducing variability in service times — making the slow cases less slow — often helps more than speeding up the average.
Why One Shared Queue Beats Several Separate Ones
Compare two arrangements with the same total capacity. Four separate M/M/1 queues each handling a quarter of the arrivals, against one M/M/4 queue handling all of them. The utilisation is identical in both. The waiting time is not: the pooled arrangement is dramatically better, because an idle server can always take the next arrival, whereas in the separate arrangement a customer can be stuck behind a slow job while another server sits empty.
Run it through the tool. Four separate queues at λ = 8 and μ = 10 each give Wq = 24 minutes. One shared queue at λ = 32 with four servers at μ = 10 gives Wq of about 4.5 minutes. Same staff, same work, more than five times less waiting, purely from removing the possibility of an idle server next to a waiting customer. This is the reason banks and airports replaced per-counter lines with a single serpentine queue, and it is one of the few operational changes that costs nothing and improves things measurably.
The same pooling logic explains why adding a server helps most when utilisation is already high. At 50 per cent utilisation there is little queue to remove. At 95 per cent, one extra server can move the system from an 18-customer average queue to a fraction of one. The employee cost calculator puts a figure on what that server costs, which is the other half of the staffing decision.
Little's Law, and Why It Always Holds
Little's Law states that L = λW: the average number in the system equals the arrival rate times the average time in the system. It also holds for the queue alone, as Lq = λWq. Check it against the defaults: L is 4, λ is 8 per hour, W is 0.5 hours, and 8 × 0.5 = 4. It works.
What makes the law remarkable is how few assumptions it needs. It does not require Poisson arrivals, exponential service times, or any particular queue discipline. It holds for essentially any stable system in which things arrive, spend time, and leave. That makes it the most useful thing on this page for real work, because you can apply it to systems the M/M/c model does not describe at all. If you know how many support tickets are open on average and how many arrive per day, you know the average resolution time without measuring a single ticket's lifecycle. The lecture notes for that MIT course devote six sessions to queueing systems and state the law's conditions precisely.
The Assumptions, and When They Fail
The first M in M/M/c means arrivals follow a Poisson process — random, independent, at a constant average rate. That fails when arrivals are scheduled, when they come in coaches or batches, or when the rate swings by time of day. A restaurant does not have a constant arrival rate; it has a lunch peak, and modelling the whole day at the average rate will understate the lunchtime queue badly. The usual fix is to model each period separately at its own rate.
The second M means service times are exponentially distributed, which implies enormous variability — many very short jobs and a few very long ones. Real service is often far more consistent than that, and when it is, the model overstates the queue. It also assumes the queue can grow without limit and that nobody gives up and leaves. Real customers abandon, real waiting rooms fill, and both effects reduce the observed queue while making the service worse in ways the model does not capture. Treat the output as an upper-bound sketch of a variable system rather than a forecast, and note that the exponential distribution calculator will show you what that service-time assumption actually looks like.
Arb Digital looks at where load, latency and drop-off actually bite, rather than at the average that hides the peak.
Browse All Free Tools Talk To Our TeamCommon Mistakes to Avoid
- Mixing rates and times — μ is a rate per hour, not a duration. A six-minute service means μ = 10, not μ = 6.
- Averaging across peaks and troughs — the model assumes one constant arrival rate. Feeding it a daily average will badly understate the queue during the busy period.
- Planning for utilisation above about 85 per cent — the waiting time curve turns almost vertical beyond that, so small forecasting errors produce very large queue errors.
- Treating separate queues as equivalent to a pooled one — the same servers arranged as one shared line produce far shorter waits, and the model reflects that.
- Quoting the average as though it were the experience — waiting times in these systems are highly skewed, so a large minority of customers wait considerably longer than the mean.
Related Free Tools From Arb Digital
Work with the arrival probabilities directly using the probability calculator, model the number of trials until a first success with the geometric distribution calculator, compute the factorial terms that appear in the Erlang C formula with the factorial calculator, or approximate a busy system's totals using the normal distribution calculator. The full free online tools hub lists every operations and statistics calculator we publish.
Frequently Asked Questions
The first M means arrivals follow a Poisson process, the second means service times are exponentially distributed, and the 1 is the number of servers. M/M/c is the same model with c identical servers sharing one queue.
There is no steady state. The queue grows without limit for as long as the overload continues, so no finite average waiting time exists and the calculator reports the instability rather than a number.
Because every formula divides by one minus the utilisation. As that term approaches zero the queue grows hyperbolically, so the last few percentage points of capacity cost far more waiting time than the first fifty.
The average number in the system equals the arrival rate multiplied by the average time in the system. It holds for almost any stable queue, regardless of the arrival or service distributions.
Yes, substantially. Pooling means no server sits idle while somebody waits, which shortens the average wait considerably for the same staff and the same workload.
It gives the probability that an arriving customer finds every server busy and must wait. It is the standard sizing calculation for contact centres and is reported here as the probability of waiting.
Not reliably. Scheduled or batched arrivals are not Poisson, and the model will overstate the queue because it assumes far more randomness than such a system actually has.
This page explains an operations research model for educational purposes only. It is not business or staffing advice, and its outputs rest on assumptions that should be checked against your own measured data.
