What expected behaviour means in a bug report, and what to write when you never had one

You are filing a bug report, the box says Expected behavior, and you have nothing to put in it. You know what went wrong. You did not hold a prior opinion about what should have happened instead, and the form is now asking you to reconstruct a belief you never consciously had. That is the ordinary case, not a lapse of attention, and there are three honest things to write in that box rather than leaving it empty.

What the box is asking for

Expected behaviour is what you believed would happen, before it did not. Actual behaviour is what happened instead, stated literally, including when the answer is nothing at all; "it doesn't work" hides at least eight different outcomes. The gap between the two is the bug, so a reader given only one half fills in the other from their own assumptions.

Templates differ on how they ask for the pair. GitHub's own default bug report template has an Expected behavior heading and no Actual behavior to match it; what actually happened goes under Describe the bug. Plenty of projects add the second box themselves. Either way both halves are wanted. The bug report guide covers what each half needs and the reproduction steps guide covers where they belong among the steps. This page covers the case neither does, when the expected line is genuinely blank.

When you never had an expectation

Holding no prior belief about what a button will do is the normal condition of using software. You know something went wrong, which is not the same thing. Three substitutes work, and all three are honest.

What you were trying to get done. State the task rather than the click. "I was trying to send the finance team a copy of the report" carries an expectation without pretending you held one: the file was meant to be complete.

The tell. What made you stop and think something was wrong? Something did, or you would not be filing. "The file opened instantly and I knew it should take longer" is a real observation, and often the shortest route to the defect.

What you would have accepted. An expectation formed after the fact is still an expectation and is completely legitimate to write down. "A warning saying it had been truncated would have been fine" tells a reader exactly what a fix looks like.

"I did not expect it to do that" and "I expected an error rather than silence" are both real expectations. Either one beats leaving the box empty.

What a reader can recover, and what they cannot

Anybody working from your text alone, a stranger on the triage rota or whatever reads the issue before a human does, can recover an expectation you implied, because the task implies the outcome. "I was exporting the report to email to the finance team" implies the row count should have matched the screen. "The export is broken" implies nothing.

So an unstated expectation is not ambiguity that a closer reading resolves. It is missing information, and the only way to recover it is to ask you, which costs a round trip and however long you take to see the question. Writing one of the three lines above is how you avoid being asked what should have happened instead.

When the answer is that it never did this

Sometimes the expectation came from you rather than from the documentation or the interface. That is the line separating a defect from a product decision, and what you are filing is closer to a feature request. Write that in the box; it beats N/A, which only tells the reader that the question did not fit.

The second author had no expectation either. They wrote down what they were doing and what made them stop, and the expectation is now recoverable by anybody who reads it.