Guides 16 of 17 · Account & help
On this page 15 sections
Troubleshooting
7 min read
Most "it should work!" moments have a short, specific cause. Here are the ones we see most, and how to read your way out of them.
This is the single most common one, and it almost always means your code is correct on the visible samples but not on the hidden suite, which deliberately includes the cases the samples leave out:
- Edge cases: empty input, a single element, all-equal elements, negatives, the maximum
value, an empty string,
nullwhere it's allowed. - Scale: inputs large enough that an inefficient solution times out even though it's
logically right. If the failing test name mentions a large
n, this is your problem; see Writing fast C#.
Open the Tests tab and select Only failing when it appears. Read the verdict, test name, status, and budget or rule detail before changing code. Then add the nastiest small custom input you can think of and Run it.
A timeout means your code exceeded the per-test time budget. It ran, it may even be correct, but not fast enough. Nine times out of ten the cause is complexity, not a slow line. An O(n²) approach on a large hidden input cannot be tuned into passing; it has to become O(n log n) or O(n). Start with the three questions in Writing fast C#.
The grader caught an unhandled exception. The result shows the exception type and message; read it first, it's usually decisive:
| Exception | Usual cause |
|---|---|
NullReferenceException |
An input or intermediate value was null and you dereferenced it. |
IndexOutOfRangeException |
An off-by-one, or you assumed a non-empty collection. |
ArgumentException / FormatException |
Parsing input that isn't in the shape you assumed. |
OverflowException or a wrong huge number |
An int that should have been a long. |
StackOverflowException |
Unbounded recursion; add the base case or go iterative. |
Compile errors come back with the full compiler diagnostics, and they show up inline in the editor as red underlines. A few platform-specific gotchas, beyond ordinary typos:
- You renamed
Solutionor the entry method. The grader binds to them by name. Keep the class and method signature exactly as the starter gives them. See The editor & runtime. - A missing
using. Implicit usings aren't on; add the namespace yourself at the top. - You reached for a NuGet package or
unsafe. Neither is available. Use the base class library only, andunsafeis disabled by design. - You wrote a
Main/ top-level statements. Submissions are a library; put the logic in the method instead.
That is intentional, not a bug. Hidden tests reveal their name, status, timing, and applicable budget or rule evidence, but never the input, expected output, or your output. Read the test name; it points at the kind of case you are missing.
Console.WriteLine output is shown when you Run, next to the return value. Submit hides
it. Grading reports pass/fail, timing, and allocations, not your trace. If you need to see
what your code printed, Run it.
Your in-progress code autosaves per puzzle, in this browser. Two things clear it: hitting
reset (which deliberately restores the original starter), and clearing your browser's site
data (which wipes the local save). If a puzzle looks blank when you expected your work, you
most likely reset it: right after a Reset, select Undo in the notice over the editor (in a
single-file puzzle Ctrl/Cmd + Z works too). Use Reveal solution to study a correct version,
then Reset and try again.
When you are signed in, unfinished code is also saved to your account as a draft and restored on any device. A solved puzzle with no draft opens on your accepted solution, which is expected. If the workspace shows "We couldn't load this private workspace", select Retry private workspace.
Run, Submit, and Reveal have separate allowances on Free. Running samples does not spend a submission, but it does use the run allowance. Revealing does not spend a run or submission, but it does use the reveal allowance.
Read the limit message and the usage indicator in the Playground header. It identifies the relevant allowance and reset. If a paid plan still shows a Free limit after checkout, refresh once, then open Account & billing and confirm that the plan card shows the paid plan and an active status.
A path step completes only after a clean Submit. Run, hints, and Reveal do not complete it. Open the path detail page and check which exercise is the next incomplete step. If the puzzle shows solved but the signed-in path does not update, refresh the path page so it can reconcile the latest history.
First confirm that Labs appears in the app and that the selected Lab is included in your plan. During workspace preparation:
- use Try again if the preparation screen reports a temporary failure;
- if another Lab session is active, choose Close it and start here, or resume that workspace;
- keep the preparation page open until the workspace is ready;
- after a session has ended, choose Start a new workspace to create a fresh one.
If the editor alone fails to load, choose Reload editor. The Lab session can remain healthy even when the browser editor needs another attempt.
Lab workspaces are a shared, capped pool. When every one is in use, the preparation screen shows your position in the queue and counts down to an automatic retry; choose Try now to retry immediately. Nothing about your course progress is affected by waiting.
Check lists every requirement it evaluated. Fix each failed row, then Check again. Make sure unsaved
changes were sent by selecting Check, Build, Run, or Ctrl/Cmd + S. In terminal-led Labs, confirm
that a guide command was sent to the intended terminal and has finished before checking.
Next remains locked until the current lesson's checks pass. Showing the solution changes the file but does not bypass Check.
A System Design result can come back rejected with a note that the design could not be simulated within the safety budget. The structural rules are still evaluated and shown. Simplify the topology toward the challenge's component and connection budget, remove connections the brief does not ask for, and Check again. See Using the System Design Studio.
Manage billing appears for an account with a paid subscription. Free accounts see View plans instead. If the plan card shows Payment failed, select Update payment method; if it shows Paused, open the customer portal from Manage billing. If the page says it could not load your plan, select Try again. If the portal cannot open after retrying, contact support from the email used for the Katabench account.
If something still looks wrong, email support@katabench.com with the puzzle, path, course, Lab, or lesson name; the action you selected; the exact message; and whether a retry changed it. For billing, write from the address used by your Katabench account. Never send a password or full payment-card number.