Home / Operations Research / Queuing Theory Calculator
Operations Research and Stochastic Models
Queuing Theory Calculator (M/M/1, M/M/c, M/M/1/K)
In short: queuing theory turns arrival and service rates into waiting-line metrics. Pick a model and enter the rates below, and this tool returns utilization, the average number in queue and system, the average wait, the probability of waiting, and a curve showing how the queue explodes as utilization rises.
Compute waiting-line metrics
ρ = λ / (c·μ) · M/M/1, M/M/c (Erlang C), M/M/1/K → L, Lq, W, Wq
Average number in system (L)
4
Enter rates to compute the waiting-line metrics.
What queuing theory does
Queuing theory is the mathematics of waiting lines, and it answers the questions every operations manager faces when arrivals are random and service takes time: how long is the line, how long do people wait, and how busy are the servers. From three inputs, the rate at which customers arrive, the rate at which each server works, and the number of servers, it derives the long-run averages that describe the system: the number waiting, the number in the system, the time spent waiting, and the utilization of the servers. Those numbers turn a vague sense that “the line is too long” into a quantified basis for deciding how many servers, chairs, or channels a system needs.
The central and often counter-intuitive lesson of the field is that queues form long before a system is fully loaded, because arrivals and service times vary. A checkout that could in principle handle every customer if they arrived evenly still builds a line, because in reality customers cluster and some services run long. As utilization climbs toward full, the average wait does not rise gently but explodes, which is why a system run flat out is a system with an enormous queue. Understanding that non-linear relationship, and planning deliberate spare capacity because of it, is what separates a well-run service operation from one that is perpetually behind.
This calculator implements the three models an engineer meets first, written in the standard Kendall notation. M/M/1 is a single server with random (Poisson) arrivals and variable (exponential) service. M/M/c extends that to several servers sharing one queue, using the Erlang C formula at the heart of call-center staffing. M/M/1/K adds a finite capacity, so arrivals are turned away when the system is full.
Choose a model, enter the rates, and the tool returns utilization, the average number in queue and in system, the average wait and time in system, the probability an arrival must wait, and, for the finite model, the blocking probability. It also plots how the queue grows with utilization and flags the unstable case where the queue would grow without bound.
Everything runs in your browser, and nothing you enter is stored.
How this calculator works, step by step
Begin by choosing the model. Use M/M/1 for a single server, M/M/c when several servers share one waiting line, and M/M/1/K when the system can hold only a limited number of customers and turns the rest away. The input fields adjust to the model: the number of servers appears for M/M/c, and the capacity appears for M/M/1/K. The calculator opens on an M/M/1 example so you can see a complete, correct result before changing anything.
Then enter the two rates in consistent units. The arrival rate lambda is how many customers arrive per unit of time, and the service rate mu is how many one server could complete per unit of time if it never went idle. Both must use the same time unit, per hour, per minute, per day, and the results come back in that unit: a wait computed from per-hour rates is in hours. For M/M/c also enter the number of servers, and for M/M/1/K the maximum number the system can hold. The tool re-computes live as you type.
The result panel headlines the average number in the system and lists the full set of metrics: utilization, the average number in queue and in system, the average wait in queue and total time in system, the chance the system is empty, and the chance an arrival has to wait. For the finite model it adds the blocking probability and the effective arrival rate, the portion actually admitted.
The chart shows how the average queue length climbs as utilization rises, with your current operating point marked, so the non-linear blow-up near full utilization is visible at a glance. If you enter rates that overwhelm an infinite-capacity system, the tool reports it as unstable rather than returning a meaningless finite number.
Download a PDF or CSV or share the result; all of it happens locally.
Kendall notation and the three models
Queuing models are labelled in Kendall notation, a compact code of the form A/B/c/K where A is the arrival process, B is the service-time distribution, c is the number of servers, and an optional K is the system capacity. The letter M, for Markovian or memoryless, denotes Poisson arrivals in the first position and exponential service times in the second; these are the assumptions that make the models solvable in closed form, and they represent a specific, fairly high level of variability. Reading the notation tells you immediately what a model assumes, which is why it is worth knowing even if you only ever use the three most common cases.
M/M/1, one server, is the starting point and the model behind much of the intuition: from the single ratio of arrival to service rate it gives every metric in simple closed forms.
M/M/c generalizes to several identical servers drawing from one shared queue, the arrangement of a call center or a bank teller line, and its Erlang C formula captures the crucial efficiency of pooling, a shared queue feeding many servers waits far less than the same servers each with a private line.
M/M/1/K caps the number in the system, modelling a limited waiting room or buffer, and because it can turn arrivals away it introduces a blocking probability and remains stable even under heavy load. Together these three cover the large majority of first-pass capacity questions, and this calculator switches between them from a single control.
Five worked examples you can follow
Example 1: the single-server default
The calculator opens on M/M/1 with an arrival rate of 8 and a service rate of 10 per unit time. Utilization is 0.8, so the single server is busy 80 percent of the time. The average number in the system is 4, with 3.2 of them waiting in the queue; the average time in the system is 0.5 time units, of which 0.4 is spent waiting. Notice that at 80 percent utilization the server already carries a queue of more than three, a direct consequence of variability, and the chart shows how much steeper the climb becomes just beyond this point.
Example 2: adding a second server
Switch to M/M/c and set two servers with the same rates, arrival 8 and service 10 each. Total capacity is now 20 against a load of 8, so utilization falls to 0.4 and the queue nearly vanishes: the average wait drops to a small fraction of a time unit. This is the pooling effect in action, and it illustrates why the right question is rarely “can one server keep up on average” but “how many servers keep the wait acceptable,” since the second server buys far more than it costs once the cost of waiting is counted.
Example 3: the utilization trap
Keep M/M/1 and raise the arrival rate from 8 to 9 with the service rate still 10. Utilization rises only from 0.8 to 0.9, a modest ten percent change in load, but the average number in the system jumps from 4 to 9 and the wait more than doubles. This is the non-linear trap at the heart of the subject: near full utilization, a small increase in demand produces a large increase in delay. It is why systems that feel fine at 80 percent fall apart at 90, and why spare capacity is not waste but insurance.
Example 4: a finite waiting room
Switch to M/M/1/K with arrival 8, service 10, and a capacity of 5. Now at most five customers can be in the system and any who arrive when it is full are turned away. The tool reports a blocking probability, the fraction of arrivals lost, and an effective arrival rate, the fraction actually admitted, and it computes the queue metrics for those who get in. Unlike the infinite model, this one stays stable even if you push the arrival rate above the service rate, because the cap prevents the queue from growing without bound; the price of stability is customers turned away.
Example 5: an unstable system
Return to M/M/1 and set the arrival rate to 10 with a service rate of 8. Now demand exceeds capacity, utilization is 1.25, and there is no steady state: the queue grows forever. The calculator reports this as unstable rather than returning a number, because any finite answer would be false. The fix is one of three levers, add a server, speed up service, or cap the system with the finite model, and seeing the tool refuse to invent a number is itself the lesson that you cannot serve more than you have capacity for.
Three expert tips for sizing capacity
Pool queues wherever you can
One shared line feeding several servers waits far less than the same servers with separate lines. Model it as M/M/c, not several M/M/1s, and design the real system the same way.
Never plan for full utilization
Because delay explodes near ρ = 1, a system sized for its exact average load will have a huge queue. Build in spare capacity deliberately; it is insurance against variability, not waste.
Match the time units
Arrival and service rates must share one time unit, and every time result comes back in it. Mixing per-hour and per-minute rates is the most common error and silently corrupts the wait.
Why lines form below full capacity
The most important single idea in queuing theory is the shape of the curve relating delay to utilization, and it is the reason the field exists at all. As the utilization rho climbs from low values, the average queue grows slowly at first, then bends sharply upward, rising toward infinity as rho approaches one.
For the single-server model the average number waiting is proportional to rho squared divided by one minus rho, and it is that one-minus-rho in the denominator that drives the explosion: at eighty percent utilization the denominator is 0.2, at ninety percent it is 0.1, at ninety-five percent it is 0.05, so each step toward full load roughly doubles the wait again.
The calculator draws this curve for your model and marks where you are on it, which is often more persuasive than any single number.
The practical consequences are large and frequently ignored. A manager who sees a server busy eighty percent of the time may reason that there is twenty percent of headroom and push more work through, only to find the queue tripling as utilization moves to ninety. The correct mental model is the opposite: the last increments of utilization are extraordinarily expensive in delay, so the useful operating range ends well before full load.
This is why call centers staff to a wait target rather than to break-even utilization, why highways jam at a flow well below their theoretical maximum, and why a factory run at a hundred percent of capacity accumulates enormous work-in-process. Spare capacity is the price of short queues, and the curve shows exactly how much you must hold to keep the wait where you want it.
Reading the curve, not just the average, is what turns queuing theory from a set of formulas into a planning discipline.
Little\u2019s Law: the identity that ties it together
Underlying all of these metrics is a single, remarkably general relationship known as Little\u2019s Law: the average number of items in a stable system equals the average arrival rate multiplied by the average time an item spends in the system, written L = lambda times W, with the same relationship Lq = lambda times Wq for the queue alone. What makes it powerful is its generality: it holds for essentially any stable queuing system, regardless of the arrival pattern, the service distribution, the number of servers, or the queue discipline. It is not a property of the M/M assumptions; it is a conservation law about flow.
The law is why this calculator can move so freely between counts and times, and why you only ever need to know a couple of the quantities to recover the rest. If you can observe how many customers are in a system on average and how fast they arrive, you can infer the average time they spend without timing anyone directly, a trick used constantly in practice to measure lead times that are hard to observe.
It also connects queuing theory to the rest of operations: the same identity, expressed as inventory equals throughput times flow time, governs work-in-process on a factory floor and is the backbone of the lean and supply-chain tools elsewhere on this network.
Recognizing that the waiting-line metrics and the inventory metrics are the same law in different clothes is one of the unifying insights of operations management, and it means an intuition built here transfers directly to those other domains.
Sizing servers: staffing to a service target
The most common real use of these formulas is deciding how many servers to provide, and the method is to compute a service measure for several server counts and pick the smallest count that meets a target. The target is usually stated as a waiting-time promise or a probability of waiting, for example that the average wait stays under a minute, or that no more than twenty percent of arrivals have to wait at all. Because the Erlang C probability of waiting and the average wait both drop steeply as you add servers near high utilization, the calculation typically produces a clear answer rather than a knife-edge trade-off: one server is hopeless, another is comfortable, and a third buys little.
Two refinements matter in practice. First, demand is rarely constant: arrival rates swing by hour of day and season, so the right staffing is a schedule that tracks the arrival curve, computed by applying the model to each period rather than to a daily average, since averaging hides the peaks where queues form.
Second, the decision is ultimately economic: each server has a cost, and waiting has a cost too, whether in lost customers, idle machines, or paid time, and the best staffing minimizes the sum of the two. The queuing model supplies the waiting side of that equation for any staffing level, so you can lay the cost of servers against the cost of delay and choose the minimum.
This is exactly how call centers, emergency departments, and maintenance crews are sized, and the same M/M/c model this calculator runs is the engine inside the specialized workforce-management tools that do it at scale.
Where the memoryless assumptions bite
The M/M models rest on two assumptions worth understanding before trusting their numbers. Poisson arrivals mean customers arrive independently at random, with the memoryless property that the chance of an arrival in the next instant does not depend on how long it has been since the last one.
This fits many situations well, calls into a large center, customers into a busy shop, failures across a big fleet of machines, because the aggregate of many independent sources is close to Poisson.
It fits badly when arrivals are scheduled, batched, or strongly correlated, such as an appointment system or a shuttle that dumps a busload at once, where the real arrival pattern is far more regular or far more clustered than Poisson.
Exponential service times are the rougher assumption. The memoryless property implies that a service already in progress is no more likely to finish soon than one just started, and that short services are common while occasional ones run very long. Real service is often more consistent than that, a scan, a transaction, a machining step that takes nearly the same time every go, and when service is more regular than exponential the true queue is shorter than the M/M model predicts.
This means the M/M result is generally conservative: it tends to overstate the queue when service is regular, so using it to size capacity errs on the safe side. When accuracy matters, the M/G/1 model relaxes the service distribution to anything with a known mean and variance, and the Pollaczek-Khinchine formula shows the queue shrinking as service variability falls, reaching about half the M/M queue when service is perfectly constant.
For a first-pass sizing the M/M models this calculator provides are the standard and usually sufficient tool, and knowing they lean conservative is part of using them well.
Common mistakes to avoid
A handful of errors recur and distort waiting-line decisions. Watch for these.
- Mismatched time units. Arrival and service rates must share one time unit. Mixing per-hour and per-minute figures silently produces a wildly wrong wait.
- Modelling shared servers as separate queues. Several servers on one queue (M/M/c) wait far less than the same servers each with a private line. Splitting them throws away the pooling benefit.
- Planning to full utilization. Because delay explodes near ρ = 1, sizing for the exact average load guarantees a long queue. Staff to a wait target with spare capacity.
- Using a daily average for a peaked day. Averaging arrivals over a day hides the peaks where queues actually form. Apply the model to each busy period separately.
- Trusting a number from an unstable system. If utilization is at or above one for an infinite model, there is no steady state and any finite figure is false. Add capacity or use the finite model.
- Forgetting service time in W. The total time in system includes the service itself, not just the wait. Confusing W with Wq understates or overstates depending on which you need.
- Assuming exponential service without checking. If service is far more regular than exponential, the real queue is shorter; the M/M estimate is conservative, which is safe for sizing but pessimistic for expectation-setting.
Where this model fits in the toolkit
Queuing theory answers the capacity-and-waiting questions that other operations tools take as given. The Operations Research hub groups it with the other stochastic and optimization models for that reason.
Where the linear programming calculator optimizes an allocation under fixed constraints, queuing theory tells you what one of those constraints, service capacity, actually needs to be to keep waiting acceptable, so the two are complementary: queuing sizes the resource, optimization allocates it.
When a system moves between discrete states over time rather than simply forming a line, the Markov chain model generalizes the same probabilistic thinking.
Beyond this silo, the waiting-line metrics connect directly to the flow and inventory tools through Little\u2019s Law, which is the same identity whether it counts customers in a queue or work-in-process on a line.
The lead-time and throughput ideas in the lean and supply-chain silos are queuing insights in another vocabulary, and the variability that drives queues is the same variability that safety stock buffers against.
In a broad sense, any place where work waits, calls on hold, patients in a waiting room, jobs before a machine, parts before assembly, is a queue, and the models here are the quantitative core of managing all of them. Return to the Operations Research hub for the full set of models.
Erlang and the origin of the field
Queuing theory has a precise birthplace: the Copenhagen Telephone Company in the years around 1909, where a young Danish engineer named Agner Krarup Erlang set out to answer how many circuits a telephone exchange needed so that callers would rarely find all lines busy. His analysis of calls arriving at random and holding lines for variable times produced the first queuing formulas, including the loss and delay formulas that still bear his name, and it founded an entire discipline. The unit of offered traffic load, the erlang, is named for him, as is the Erlang C formula this calculator uses for multi-server delay and the Erlang B formula for systems that block rather than queue.
The field grew from that telephone origin into a general theory of congestion applicable far beyond communications. The same mathematics that sized exchanges now staffs call centers and hospitals, dimensions computer networks and server farms, lays out checkout lanes and toll plazas, and schedules machine maintenance, because all of them share the structure of random arrivals meeting limited service.
Queuing theory sits within the broader field of stochastic processes and connects to Markov chains, of which the M/M models are a special case, but its enduring appeal is practical: with three numbers it turns the universal experience of waiting into something you can predict and design for.
That Erlang\u2019s century-old formulas remain the working tools of capacity planning across so many industries is a testament to how well the abstraction captures the real thing.
From observations to a model: measuring your rates
A model is only as good as the two rates you feed it, and getting them right is the practical work that surrounds the arithmetic. The arrival rate is the easier of the two: count arrivals over a representative stretch of time and divide by its length, taking care that the stretch really is representative rather than an average that blends a quiet morning with a frantic lunch. Because queues form in the peaks, not the daily mean, the right practice is to break the day into periods over which the arrival rate is roughly steady, an hour or a half-hour, and model each separately; a single daily average will understate the peak queues badly and lead you to under-provide exactly when it hurts.
The service rate takes more care, because it must be the rate one server achieves while actually working, not the throughput of the whole system and not diluted by idle time or breaks. Time a sample of services from the moment work begins to the moment it ends, average those durations, and invert: a mean service time of six minutes is a service rate of ten per hour. Keep the units identical to the arrival rate. It is worth timing enough services to see their spread, because that spread is what the exponential assumption is standing in for, and if you find service is remarkably consistent you know the M/M estimate will run conservative and the real queue will be somewhat shorter.
Two checks prevent most modelling errors. First, confirm the system is genuinely stable before trusting any infinite-model number: total service capacity, the service rate times the number of servers, must exceed the arrival rate, or the tool will rightly report the system as unstable. Second, sanity-check the result against reality if you can observe it: if the model says the average line is two but you routinely see ten, either the rates are measured wrong, the arrivals are far more clustered than Poisson, or a period of overload is being averaged away.
The model is a lens, not an oracle, and comparing its prediction with what you can actually see is how you learn whether its assumptions fit your system well enough to plan on.
A short pilot, measuring rates for a week, modelling each period, and then checking the predicted queue against the observed one, is time well spent before any capacity decision rides on the numbers, and it usually reveals quickly whether the simple M/M model is close enough or whether the arrivals and service in your particular system depart from its assumptions enough to need a richer one.
Input format and quick reference
Choose a model, then enter the arrival rate and the per-server service rate in the same time unit; add the number of servers for M/M/c or the capacity for M/M/1/K. Every time-based result comes back in whatever unit you used for the rates. The reference below summarizes the metrics the calculator returns.
| Symbol | Meaning |
|---|---|
| ρ (rho) | Utilization: fraction of server capacity in use; must be below 1 for the infinite models |
| L | Average number of customers in the system (waiting plus in service) |
| Lq | Average number waiting in the queue, not yet served |
| W | Average total time in the system (wait plus service) |
| Wq | Average time spent waiting in the queue |
| P0 | Probability the system is empty |
| Prob. wait | Probability an arriving customer must wait (Erlang C for M/M/c) |
| Blocking (Pk) | M/M/1/K only: probability an arrival finds the system full and is turned away |
Frequently asked questions
What is queuing theory?
Queuing theory is the mathematical study of waiting lines: how they form, how long they get, and how long people or jobs wait in them. It models a system by an arrival process (how customers show up), a service process (how fast they are served), and the number of servers, then derives the long-run averages such as the number waiting, the number in the system, and the average wait. It is used to size call-center staffing, hospital capacity, checkout lanes, machine repair crews, and computer systems, anywhere arrivals are random and service takes time.
What do the letters in M/M/1 mean?
M/M/1 is Kendall notation. The first letter is the arrival process, the second is the service-time distribution, and the number is how many servers there are. M stands for Markovian, meaning arrivals follow a Poisson process and service times are exponential, the memoryless assumptions that make the model tractable. So M/M/1 is a single server with Poisson arrivals and exponential service; M/M/c is the same with c parallel servers sharing one queue; and M/M/1/K adds a maximum system capacity of K, beyond which arrivals are turned away.
What is utilization and why does it matter so much?
Utilization, written ρ (rho), is the fraction of the servers\u2019 capacity that the arriving work demands: for a single server it is the arrival rate divided by the service rate, and for c servers it is the arrival rate divided by c times the service rate. It matters because waiting time and queue length rise non-linearly as ρ approaches 1: a system at 90 percent utilization has far more than twice the queue of one at 80 percent. When ρ reaches or exceeds 1 for an infinite-capacity model, the queue grows without bound and no steady state exists, which this calculator flags as unstable.
What is the difference between Lq and L, or Wq and W?
Lq is the average number of customers waiting in the queue, not yet being served; L is the average number in the whole system, including those in service, so L is always larger. Likewise Wq is the average time a customer spends waiting before service begins, and W is the total time in the system, waiting plus service, so W equals Wq plus the average service time. Which one you want depends on the question: Lq and Wq describe the waiting experience, while L and W describe the total load and time in the system.
When should I use M/M/c instead of M/M/1?
Use M/M/c whenever several servers draw from a single shared queue, which is the usual arrangement for call centers, bank teller lines, and help desks. It is important not to model c servers as c separate M/M/1 systems, because a shared queue is far more efficient than splitting arrivals among separate lines: a single queue feeding several servers has a much shorter wait than several independent queues with the same total capacity. The M/M/c model, using the Erlang C formula, captures that pooling benefit, which is a central insight of queuing theory.
What is the Erlang C formula?
Erlang C is the formula that gives the probability an arriving customer has to wait in an M/M/c system, that is, the probability all c servers are busy. It is the core of multi-server queuing and the basis of call-center staffing: from it the calculator derives the average queue length, waiting time, and the other metrics. It is named for Agner Krarup Erlang, the Danish engineer who founded queuing theory in the early twentieth century while studying telephone exchanges, which is also why the unit of offered load is called the erlang.
What does the M/M/1/K model add?
The M/M/1/K model adds a finite system capacity K: at most K customers can be in the system, and any arriving while it is full are turned away, or blocked. This makes it the right model for a waiting room with limited chairs, a buffer of limited size, or a call system with a maximum number of held calls. Because arrivals are lost when full, it reports a blocking probability and an effective arrival rate (the rate actually admitted), and unlike the infinite models it always has a steady state even when the arrival rate exceeds the service rate, since the queue cannot grow past K.
Why do queues form even when the server is not fully busy?
Because arrivals and service times vary. If customers arrived exactly evenly and every service took exactly the same time, a server with any spare capacity would never build a queue. Real arrivals cluster and real service times differ, so even at moderate utilization a run of quick arrivals or slow services creates a temporary backlog that takes time to clear. Queuing theory quantifies this: the average queue depends not just on utilization but on that variability, and the memoryless M/M assumptions represent a specific, high level of it. The practical lesson is that you must plan for spare capacity, because a system sized for exactly its average load will have long queues.
What is Little\u2019s Law and how does it relate?
Little\u2019s Law is the simple, powerful identity that the average number in a system equals the average arrival rate times the average time spent in the system: L = \u03bb W, and likewise Lq = \u03bb Wq. It holds for almost any stable queuing system regardless of the arrival or service distribution, which is why this calculator can convert between counts and times so freely. It means that if you know any two of the three quantities, count, rate, and time, you can find the third, and it links the queuing metrics to the throughput and lead-time ideas used elsewhere in operations.
Are the Poisson and exponential assumptions realistic?
They are often a reasonable first approximation and sometimes exact. Poisson arrivals describe many independent customers arriving at random, which fits calls to a large call center or customers to a busy shop well. Exponential service times, with their memoryless property, are a rougher fit, because real service often varies less than exponential predicts. When service times are much more regular, the true queue is shorter than the M/M model says, so the M/M result is a conservative, slightly pessimistic estimate. For a first-pass sizing this is usually acceptable; when precision matters, models like M/G/1 that allow a general service distribution refine it.
Can queuing formulas tell me how many servers I need?
Yes, indirectly, and that is one of their main uses. By computing the waiting time or the probability of waiting for different server counts, you find the smallest number of servers that meets a service target, such as \u201cninety percent of callers wait less than thirty seconds.\u201d Because adding a server drops the wait sharply near high utilization, there is usually a clear right number rather than a marginal trade-off. Weigh the cost of another server against the cost of waiting, staff to the target, and re-check as the arrival rate changes by the hour or season.
Do these calculators store the numbers I enter?
No. This calculator runs entirely in your browser. The rates you enter are never sent to our servers, stored, or shared. You can download a PDF or CSV of your results locally, and nothing leaves your device. See our Privacy Policy for details.
Is the queuing theory calculator free?
Yes. The queuing theory and waiting-line calculator is completely free, with no account, sign-up, or paywall, and no limit on how often you run it. It returns utilization, the average number in queue and in system, the average wait and time in system, the probability of waiting, and for the finite model the blocking probability, with a utilization curve and PDF and CSV export at no cost.
Related operations research calculators
More tools in this silo. Return to the Operations Research hub for the full set.
Sources, disclaimer, and editorial transparency
This calculator implements the standard M/M/1, M/M/c (Erlang C), and M/M/1/K queuing formulas from the theory of stochastic processes founded by A. K. Erlang. This calculator and guide are built and reviewed by the OpsCalculators team; see our Editorial Policy for how each tool is researched, built, and tested.
Results are accurate estimates for planning and education, not certified engineering advice, and assume Poisson arrivals and exponential service; when service is markedly more regular than exponential the true queue is shorter, so treat the figures as conservative. Validate against your own data before committing capacity. See our full Disclaimer. OpsCalculators.com is operated by MAFHH INTERNATIONAL LTD. Your inputs are processed in your browser and are never stored; see our Privacy Policy.