The MCAT error log
Last updated August 16, 2026
An MCAT error log is a running record of the questions you got wrong, kept so that you can go back over them and find what keeps going wrong. Nearly every serious study plan includes one, and the advice to keep one is good advice.
It is worth being precise about why, because the reason determines what the log has to contain. A log is not kept in order to have a record. It is kept in order to answer a question — what do my misses have in common? — and that question is asked weeks after the rows are written.
This page is about that question: what an error log is for, why the usual formats struggle to answer it, and what a format would need to contain if it were going to.
What an error log is actually for
Two different jobs get bundled under the same name, and they pull in opposite directions.
- A to-do list of questions to revisit. Short-lived, useful, and mostly served by whatever your question bank already flags for you.
- A body of evidence about how you reason. Long-lived, and the reason anyone recommends keeping one. This is where the value is, and it only pays out in aggregate.
The second job is the real one. A single logged miss tells you almost nothing you did not already know when you got the question wrong. Twenty of them, read together, can tell you something you could not have seen from any one of them — that the same failure keeps appearing in different subjects, wearing a different topic each time.
Which means a log is only as good as the questions it can answer later. Everything below follows from that.
What most logs contain
The standard format is remarkably consistent across every template on the internet. Some version of:
- The question — source, number, sometimes a screenshot
- The answer you chose, and the correct answer
- The content category or topic
- An error type, picked from a short list — content gap, reasoning, careless, misread
- A one-line takeaway, and often a date to review it again
This is a sensible design. It is quick to fill in, it sorts and filters cleanly, and the field count is deliberately kept low because a format nobody maintains is worth nothing. Every one of those decisions is defensible.
And a student who fills this in faithfully for two months, then sits down to read it, usually finds it does not tell them anything. That outcome is so common it is worth explaining properly, because the usual explanation — that they were not consistent enough — is wrong.
Why those columns cannot produce patterns
Ask what that record can be sorted by. Topic, section, source, error type. So the questions it can answer are: which topics recur, and which of five error labels you selected most often.
The first is a topic tally, and your question bank already produced it on the score screen. The second is a tally of your own labels, which is a record of how you describe your mistakes rather than of the mistakes.
Neither can tell you whether the biochemistry miss in week two and the physics miss in week six were the same error. Nothing in the row describes the error. It describes where the error landed and what you called it afterwards.
The specific thing that goes missing
There is one omission that matters more than the rest, and it is nearly universal: the log records which option you chose and never records what that option said.
MCAT wrong answers are engineered. Each one is written to catch a specific, predictable error — the correct expression with a term inverted, the right answer to the second-to-last step, the familiar textbook phrase the passage never supported. So the option you selected is direct evidence of what you did.
Reduce it to the letter B and that evidence is gone permanently. B is not a fact about your reasoning. What B said was.
The label problem
The second omission is subtler. Compressing a miss into an error type from a dropdown throws away the sentence, and the sentence is where the mechanism lives. Reasoning error is true of thousands of distinct failures. “I decided it was competitive inhibition as soon as I saw the graph and never read the second half of the stem” is one specific thing that tells you what to change.
Worse, the label is your own summary — and what you say went wrong and what actually went wrong are two different things. The gap between them is often the most informative thing in the whole log, and a format that stores only the summary has thrown away the half you could have checked it against.
None of this is a failure of discipline. A student doing everything right, on schedule, with a well-designed template, still gets nothing — because the information that would have answered their question was never in the record. The format failed, not the person keeping it.
What a log would have to contain instead
Not more fields. Different information, and less of it than you would expect.
The floor for saying anything about how you reason is the text: the question stem, and what all four options actually said. With those, the option you chose becomes readable — it is possible to work out what that option was built to catch, and therefore what you did. Without them, no amount of tagging recovers it.
Above that floor, one thing adds more than anything else: a sentence, in your own words, about why your answer looked right at the time. Not a category. A sentence. It carries the mechanism, and it carries something else besides — how you wrote it. “Obviously B” and “I think B, went back and forth” describe two different states, and the second is a finding even when B was correct.
Once you have those, mistakes can be grouped by how the reasoning failed rather than by what the question was about, which is the only grouping that makes a cross-subject pattern visible. The vocabulary for that grouping is the mechanisms behind a careless miss — and doing it question by question is the per-question review procedure.
Notice what is not on this list: a topic column, a five-item error dropdown, a next-review date, a confidence score out of five. They are not harmful. They are simply not the parts that answer the question the log exists to answer.
Full log
| Question | Concept | Outcome | What happened |
|---|---|---|---|
| C/P 17 | Buffers · Henderson–Hasselbalch | Correct, but shaky | Chose the familiar buffer before checking which half of the pair was attacked |
| C/P 21 | Acid–base · pKa comparison | Incorrect | Committed on the first plausible option, did not return to the stem |
| B/B 08 | Enzyme inhibition | Correct | Affirmed the answer rather than eliminating to it |
| C/P 24 | Doppler · formula recall | Correct, but shaky | Rebuilt the formula from memory and picked the arrangement written most often |
The half that never gets logged
Every error log format shares one assumption so basic it is never stated: that the log is for wrong answers. The name says so.
But a correct answer arrives in several distinguishable ways, and only one of them is finished business. You can be right by reasoning that would not survive a small change to the stem. Right by recognising the shape of a question without ever checking whether your reason was the real one. Right by eliminating three options and taking what was left without affirming it. Right, then doubtful, then right again.
Each of those predicts a future miss, and none of them appears in a log of wrong answers. They are not mistakes yet, which is exactly why they are worth catching.
This is also the hardest habit to sustain by hand. Logging a miss has an obvious trigger — you got it wrong. Logging a correct answer requires noticing a hesitation and then choosing to write about a question you did not lose any points on, at the end of a session, when you are done. Almost nobody does it, and there is nothing wrong with them for not doing it.
How an answer is recorded
Finding patterns across weeks
A pattern needs a threshold before it is a pattern. The working one: one occurrence is an event, two is a coincidence, three is a pattern. Below three, record it and carry on.
Direction is stricter still. To say a habit is improving or worsening you need three points separated in time, which in practice means dated rows spanning three weeks or more. Three of the same failure inside one session tells you about that session. If the history is thinner than that, the honest reading is that there is not enough history yet — not a cautious arrow.
So dates matter more than they look, and they are the field most likely to be left out of a format built around individual questions.
This is also where reading your own log stops being straightforward. The third occurrence lands weeks after the first, in a different subject, usually looking like a different kind of question — and by then the first two are far enough back that you do not connect them. Recognising the third instance of something as the third instance is the entire skill, and it is the thing a document you scroll through is worst at supporting.
What you never wrote is also evidence
One reading of a log is available to anyone and almost nobody performs it: look at what is missing. A log with careless written forty times and I did not understand this written zero times is saying something definite — not about the errors, but about how they are being explained. That pattern is invisible inside any single row, and it takes reading the whole thing as one object rather than as a list.
Accuracy, read across sessions
The maintenance problem
Put the two halves together and the difficulty is clear. The information that makes a log useful — option text, a written sentence of reasoning, correct-but-shaky answers, a date on every row — is exactly the information that is slow to capture. And it has to be captured at the end of a study session, question after question, when the studying is already finished.
The standard advice resolves this by trimming: fewer fields, faster entry, a format you will actually keep. That is honest advice about human behaviour and it optimises the wrong quantity. A log you maintain for six months that cannot answer your question is not better than one you abandon — you simply find out later.
The tension is real and it does not have a good resolution as long as the log is a document you keep. Every fix for the maintenance problem removes information, and every fix for the information problem adds work at the worst possible moment.
What your tutor does instead
Studying inside CLIVEA removes the log rather than improving it. You study inside it, out loud, with a tutor in the session — so the reasoning is captured where it happens, in your words, as you give it. There is no end-of-day writing-up step, because the record was made while you worked.
That resolves the tension above rather than trading one side of it away. Nothing has to be trimmed for the sake of maintenance, because there is no maintenance: you keep no log at all. And the correct-but-shaky answers get captured along with everything else, because they were part of the session rather than something you had to decide to write down afterwards.
The analysis then reads every stored session together rather than one at a time, which is where a third occurrence registers as a third occurrence. Misses are grouped by how the reasoning failed rather than by subject, so a pattern that shows up in three different sections is visible as one finding — the full account of that is why months of work stop showing up.
Two things it will not do, worth saying plainly. It does not measure how long you spent on anything, so it makes no claims about pace. And where the history is too thin to support a trend, it says so rather than drawing one.
None of which means a hand-kept log is a waste. If you are keeping one, the changes in this page are worth making to it and none of them require any tooling. But you should know what you are getting for the effort, and you should not have to spend an hour a week building a record that was never able to answer your question.