A bill that is almost always small, occasionally huge
By now you can read a piece of code, count its loop iterations, and report a worst-case running time with a Big-O bound. That habit is usually exactly right. But it has a blind spot that shows up the moment we analyze a data structure used many times in a row rather than a single algorithm run once. Consider appending to a growable array (a Python list, a Java ArrayList, a C++ vector). Almost every append just writes one slot and returns — cost 1. But occasionally the array is full, so the append must allocate a bigger block and copy everything over — cost proportional to the current size n.
Now ask the natural question: what is the worst-case cost of one append? Honest answer: Theta(n), because the very next call might be the one that triggers a full copy. So if you analyze append the way you analyze any single operation — take its worst case — you conclude that n appends cost at most n times Theta(n) = Theta(n^2). That bound is true. It is also badly loose. The real cost of doing n appends from empty is Theta(n), not Theta(n^2). The per-operation worst case overcounted by a whole factor of n. Pinning down why, and how to get the honest Theta(n) instead, is the entire job of this rung.
Where the overcount comes from: the worst cases can't all happen
The flaw in "n appends cost at most n times the worst single append" is hidden in one innocent word: each. That bound silently assumes every operation could simultaneously hit its worst case. For a one-shot algorithm that is fine — the worst input really can make a loop run its full length. But for a sequence of operations on a shared structure, the operations are not independent. An expensive copy only happens when the array is full, and the array can only be full because many cheap appends just filled it. The conditions that make one operation expensive are the very conditions that guarantee the neighbours around it were cheap.
Make it vivid with a doubling array. Start empty with capacity 1. The copies happen at sizes 1, 2, 4, 8, 16, ..., each costing about that many element moves; in between, every append is cost 1. Over n appends the copies cost about 1 + 2 + 4 + ... up to n, a geometric sum that totals under 2n — and the cheap appends add another n. Grand total: under 3n moves, i.e. Theta(n). The expensive copies are real, but they are rare and they shrink relative to how much cheap work bought them: a copy of size n only becomes possible after n cheap appends paid the entry fee. There is simply no sequence in which every append is the expensive one.
What "amortized cost" actually means
Here is the definition, and it is refreshingly down-to-earth. The amortized cost of an operation is a number we assign to it so that, for every sequence of operations, the sum of the amortized costs is an upper bound on the sum of the true costs. We say a structure runs in amortized O(1) per append if the total true cost of any sequence of m appends is at most O(m) — equivalently, the cost averaged over the sequence is bounded by a constant. The doubling array is amortized O(1): we just saw any n appends cost under 3n, so 3 per append is a perfectly good amortized charge.
Two emphases keep this honest. First, amortized cost is a property of a sequence-summed total, established by a chosen accounting scheme, not a magic property of a lone operation in isolation. Second, the bound must hold for the worst possible sequence — there is nothing probabilistic here, no assumption about which operations are likely. That distinction matters so much it gets its own guide later; for now just hold the contrast: amortized analysis is still a worst-case guarantee, it has just stopped pretending the worst cases stack.
Three ways to do the bookkeeping
There are three standard techniques for proving an amortized bound, and the rest of this rung gives each its own guide. They always reach the same true total — they are different lenses on one reality, not competing claims — so you pick whichever makes a given problem easiest to argue. The aggregate method is the most direct: bound the total cost of n operations as a whole (exactly the geometric-sum argument we did for doubling), then divide by n to get the per-operation amortized cost. It is great when the total is easy to sum and every operation gets the same amortized charge.
The accounting (banker's) method lets different operations carry different amortized charges. You overcharge the cheap operations a little and bank the surplus as credit stored on the structure; later, an expensive operation spends that saved-up credit to pay for itself. As long as the bank balance never goes negative, the amortized charges provably cover all the true costs. The potential (physicist's) method does the same idea with a single formula instead of scattered coins: you define a potential function Phi mapping each state of the structure to a number (think "stored-up energy" or "how messy things are right now"), and the amortized cost of an operation is its true cost plus the change in Phi it causes. A cheap step that makes the structure messier prepays; an expensive step that tidies it up releases the stored potential to cover its own bill.
amortized(op) = true_cost(op) + Phi(state_after) - Phi(state_before) sum over the sequence: sum amortized = sum true_cost + Phi(final) - Phi(initial) so if Phi(final) >= Phi(initial) (and usually Phi >= 0, Phi(initial) = 0): sum true_cost <= sum amortized
The case studies this rung will earn
Three classic examples recur throughout, and seeing them now tells you why the methods are worth learning. Table doubling is the one we used above: n appends in Theta(n), so amortized O(1) each, which is why "just append to a list" is a safe everyday move despite the occasional resize. The binary counter is even cleaner: incrementing a binary number sometimes flips one bit and sometimes cascades a long carry across many bits, yet over n increments from zero the total number of bit flips is under 2n — amortized O(1) flips per increment, because bit i only flips once every 2^i increments.
The deepest case is union-find with path compression and union by rank, which you have already met as the engine inside Kruskal's MST algorithm. There a sequence of m operations runs in nearly linear total time — O(m times alpha(n)), where alpha is the inverse Ackermann function, a quantity so slow-growing it is below 5 for any n you could ever store. Per single operation the worst case is genuinely worse than constant, but amortized over the sequence each operation is effectively constant. That bound is one of the most surprising results in all of algorithm analysis, and it is pure amortized reasoning — there is no faster per-operation story to tell.
Amortized is worst-case averaging, not probabilistic averaging
One confusion is worth heading off immediately, because the word "average" sneaks into both ideas. Amortized analysis is not average-case analysis. Average-case time averages over a probability distribution of inputs — it asks "if the input is random in such-and-such a way, what is the expected cost?" — and its answer is only as trustworthy as that distributional assumption. Amortized cost averages over the operations in a sequence, with no randomness anywhere: the doubling array is amortized O(1) for the single worst sequence an adversary can choose, not merely for a typical one.
Keep this triangle of guarantees straight, because they answer different questions. Worst-case per operation is the strongest promise but, as we saw, it can hugely overcount a sequence. Amortized relaxes the per-operation promise to a per-sequence one and recovers the honest total, still with no probabilistic assumptions. Average-case and expected (as in randomized algorithms, where the randomization lives in the algorithm rather than the input) trade away the worst-case shield for assumptions about randomness. The next four guides build the amortized middle path in full — the aggregate sum, the banker's credits, the physicist's potential, and the table-doubling and union-find case studies where all three lenses agree.