Why Anki stops reviews before you expect it to

Write down where the number came from. A total collection count, a browser search result, the deck overview, and the remaining cards in a session are not interchangeable. A collection can contain cards that are not due yet, and a browser query can include cards that the study session cannot currently show. If your expectation starts from the wrong total, changing a review limit will not make the two displays agree in the way you intended.

For a first inspection, choose a few cards you believe are missing and read their current information in Browse. Are they due reviews, new material, buried siblings, or suspended cards? Check the source deck as well. A card might belong to a child deck that was not included in the session you opened. Record specific examples rather than relying only on a headline total. You need a card-level explanation before you can decide whether the queue is actually wrong.

A fictional student sees several hundred notes in a course collection but a much smaller due queue. Some notes generate two cards, some cards have future dates, and others were suspended during an earlier cleanup. The useful next action is to classify a sample of the supposedly missing cards. Counting everything as due work would create a false alarm. The review-limit control only makes sense after the student identifies which scheduled cards are available and which ones the session is allowed to gather.

Inspect the deck you selected to begin the session, then inspect its children. Anki documents that a subdeck's new-card and review limits affect what can be gathered from that subdeck, while the selected deck's limits constrain the combined session. The direction in which you enter the hierarchy therefore matters. A limit set on a child does not imply that the same number will appear when a tighter parent controls the session.

Build a harmless written example before editing. Suppose a course parent contains a biology child and a chemistry child. You expect work from both when studying the parent. List the parent limit, each child limit, and each child's available due work. The gathered session must satisfy the relevant constraints. Then compare that expectation with the session you actually started. This is a diagnostic model, not a recommendation for particular daily numbers.

Also inspect the options preset assigned to each deck. Changing a shared preset can affect more than the deck you were looking at. If you intended to change one child only, verify whether the preset is shared before saving. Write down the original values so the test is reversible. A successful diagnosis should explain why a particular session changed, rather than leaving you with several altered presets and no record of which one controlled the original behavior.

Search for the relevant card states. Suspended cards are intentionally excluded until restored, and buried siblings are temporarily withheld. A filtered deck can also hold cards away from their home deck. These are different causes from a maximum review limit. Raising a limit does not undo suspension, and repeatedly rebuilding a filtered queue will not make ineligible cards appear simply because a broader browser search can find them.

Imagine the student recently created a focused filtered deck for a quiz. Some expected cards remain there, while other sibling cards are buried. The parent course deck now looks unexpectedly quiet. The correction is to inspect those states and return material deliberately, using the documented filtered-deck controls where appropriate. It is not to reset all cards to new. Resetting would change meaningful scheduling information without explaining the selection issue that caused the apparent disappearance.

Keep a short diagnosis table in your own notes: expected card, actual state, selected deck, and next action. An entry might say "future review: wait," "suspended: inspect before restoring," or "child limit: test from the intended parent." A few explicit rows are enough. You are not building a second flashcard system; you are replacing a vague complaint with observations that can be checked one by one.

Choose a normal study context and identify the exact limit you plan to change. Record its original value, the preset, and the selected deck. Change only that control if you want to learn its effect. Then reopen the relevant overview and inspect the same sample cards. If the result still differs from your expectation, return to card states and hierarchy rather than immediately changing another unrelated setting.

Anki also offers custom-study actions to increase today's new-card or review limit. Read the current documentation before assuming every custom-study action creates a filtered deck: some change the existing deck's daily allowance instead. That distinction matters when you are trying to perform one extra session without permanently redesigning your organization. Give the action an explicit purpose, such as completing a relevant due group, and check where the cards remain afterward.

Do not treat a larger available queue as evidence that the new setting is better. It may simply expose more work than you can finish. Evaluate whether the session fits your available time and whether it protects other learning tasks. If you increased the limit to investigate an issue, restore it when the investigation ends unless you intentionally choose a new routine. A reversible test is easier to trust than a collection of unexplained permanent changes.

A review limit can be functioning correctly while your overall workload is unrealistic. If current due work routinely exceeds available time, adjust intake, relevance, or the schedule rather than hiding the mismatch behind an arbitrary queue cap. A cap can control what you see today; it does not make the underlying learning obligations disappear. Be honest about that distinction when deciding what to postpone.

Keep Anki when its scheduled queue, native note types, and history are valuable. If the real bottleneck is making sense of a source, a separate drafting workspace may help without touching those controls. You could test a permitted chapter excerpt in Elly, check the resulting questions, and keep the established Anki collection. An account and current AI allowances apply. Text migration does not preserve Anki media, templates, due dates, or review history.

Finish with a specific explanation you could give another student: the selected parent constrained the session, a preset was shared, cards were buried, or the supposed missing cards were not due. If you cannot yet give that explanation, preserve the original data and gather another small sample. The aim is a queue you understand and a routine you can sustain, not a dashboard whose counts match only because every safeguard was turned off.