Rejudging re-runs the evaluation of a submission that has already been judged, and replaces its result with the new one. You do it after changing something the old result was based on — a test that was wrong, a checker that was too strict, a limit that was too tight — and after a System failure, which usually means the problem's testing configuration was broken rather than the program.
You can rejudge a single submission, or every submission made for one problem in one contest.
Permission. In the space's Submissions list you need permission to write problems and to run testing. Inside a contest you need permission to write that contest. Without them the action isn't shown.
Fix the cause first. A rejudge re-runs against the problem as it stands now. Editing the tests, the checker or the limits afterwards means rejudging again.
It costs an evaluation. Every rejudged submission consumes one evaluation from your subscription's allowance, exactly as a new submission does. Rejudging a problem with thousands of submissions is a large bill against that quota — see Quotas and limits. The Evaluation usage counter above the submission list is where you watch it.
Not after finalizing. Once a contest is finalized, Rejudge is no longer offered — not on its submissions, and not on its problems. Finalizing stops every edit that would move an official participant's result, and there is no way back. Finish rejudging before you finalize; see Finalize results.
Open the submission, from Submissions or from the contest's Submissions tab. You can also use Rejudge in the row menu without opening it.
Choose Rejudge.
Confirm. Inside a contest, the dialog warns you that the participant's score may be affected.
The evaluation is queued, so nothing happens instantly. The list updates on its own as testing progresses; on the submission screen, Refresh reloads it, and the result also updates by itself while the run is in progress.
This is the bulk form of the same action. It covers the submissions made for one problem in that contest, not every submission of the library problem across the space.
Open the contest and go to its Problems tab.
Open the row menu of the problem and choose Rejudge.
Confirm.
The work runs in the background and can take a long time on a busy contest. A banner sits above the problem list while the retest is queued or running, linking to the contest's Activity tab, where you can follow the job and see when it finished. See Contest problems.
When it's done, rebuild the scoreboard: the standing is computed from the submissions, and after a bulk retest it can be left showing the old numbers. Rebuild is on the contest's Scoreboard tab.
The result is recomputed in place. The previous result is discarded and replaced by the new status, verdict, score and usage figures — there's no history of what the submission scored before.
Everything that identifies the submission stays as it was:
the identifier, so links and anything you've quoted still resolve;
the submission time;
its position in lists, which are ordered by that time;
the submitted source code.
A rejudge is therefore not a new attempt — nothing is added to the list, and the participant is not charged an extra try.
Rejudging does not disturb Violations: existing findings stand, and a rejudge neither creates nor clears one.
A rejudged submission can come out with a different verdict and a different score, so a participant's total can move up or down, and their rank with it. This is the whole reason the action asks for confirmation.
Rejudging one submission updates that submission's contribution. If the standing still looks wrong after a rejudge — most likely after a bulk retest, or after deleting or restoring submissions — use Rebuild on the contest's Scoreboard tab, which recomputes every participant's score from their submissions. It's a repair rather than a refresh, and it takes time on a large contest.