The grade hits your inbox at 11:47 PM on a Sunday. You open it, scroll to the bottom, and see a number that feels wrong. A 72 on the recursion assignment. A 6/10 on the linked list implementation. A big red zero on the test case that runs fine on your laptop.

Your initial reaction may be to send an angry email. The second instinct is to do nothing and hope the next assignment goes better. Both are mistakes.

A regrade request done right earns back points and sometimes repairs a relationship with a professor who misread the work. A regrade request done wrong locks in the grade, triggers a full review that surfaces deductions the grader missed the first time, and marks the student as someone who argues instead of learns.

This guide covers the decision framework, the 72-hour window most students miss, the evidence that actually changes grades, the email template that works, and the 5 mistakes that make professors reject regrades on principle. Read the whole thing before touching the email draft.

When a Regrade Request Is Worth It (And When It Backfires)

A regrade request works when the issue is factual, specific, and documented. It backfires when the issue is opinion-based, vague, or emotional. The difference matters because professors sort regrade requests into two mental piles: “grader made a mistake” and “student is unhappy.” Only the first pile receives points back.

Grading errors worth escalating

The strongest regrade cases involve 4 specific error types: arithmetic mistakes on the rubric, missed partial credit for working subcomponents, autograder false negatives on hidden test cases that pass locally, and graders marking code as wrong against the assignment specification. A working binary search tree with a failing edge case for empty trees deserves 60% credit, not 0%, when the rubric awards partial marks for partial correctness.
Evidence-backed errors get fixed fast. A student who emails their professor with a screenshot of the rubric, a screenshot of the autograder output, and a 2-line explanation of where the grader missed points usually gets a response within 48 hours.

Disagreements that rarely win

Regrade requests built on these 3 arguments almost always fail: “I spent a lot of time on this,” “the question was unclear,” and “my approach was different but still valid.” The first is irrelevant to correctness. The second is the student’s responsibility during office hours, not after grading. The third falls flat unless the assignment specification explicitly allowed alternative approaches.

The harsh reality: professors grade against the rubric they wrote, not against effort. A solution that runs perfectly but ignores the required recursion pattern on a recursion assignment deserves the deduction. Arguing “but it works” misses the point of the course.

The risk of a lower grade after regrade

A regrade triggers a fresh review of the full submission, not just the disputed section. Professors and TAs often find additional deductions on second pass: a missing docstring here, a magic number there, a naming convention violation nobody caught the first time. Gradescope explicitly warns that grades sometimes go down after regrade review.

The rule of thumb: request a regrade only when the expected gain is at least 5 points and the disputed issue is crystal clear. A regrade fight over 1 or 2 points rarely justifies the risk of a 3-point find on review.

The 72-Hour Window Most Students Miss

Most regrade requests land within 72 hours of the grade being posted, and the ones that land later face steeper resistance. Professor memory of the assignment fades fast once the next lecture starts. TAs move on to the next grading batch. The grading context that made the original mark clear disappears, and cold grading favors the original grader. Missing a regrade window feels similar to missing a submission. What Happens When You Miss a Programming Assignment Deadline? covers the broader consequences of timing failures in CS courses.

Typical regrade deadlines on Canvas, Gradescope, and Blackboard

Canvas courses typically allow 7 days for regrade requests via course comments or instructor email. Gradescope’s built-in regrade request feature opens a window of 3 to 14 days, configured by the instructor per assignment. Blackboard relies on course-level policies, usually stated in the syllabus, that range from 3 days to 2 weeks.
The syllabus is the source of truth. A regrade request submitted 1 day past the stated window gets auto-denied by most instructors on principle, regardless of the merits.

What resets the regrade clock

The regrade clock resets in 2 specific scenarios: a professor’s office hours conversation that raises a new interpretation of the grading and a clarification email from the professor that changes the basis for the original grade. Neither is common. Do not assume the clock resets because of a holiday, a personal issue, or a “please reopen the request” email.

Why acting within 3 days beats acting within 2 weeks

A regrade request filed within 72 hours benefits from 3 things that disappear later: fresh professor memory of the grading session, a batch processing workflow where TAs handle regrades in one sitting, and a baseline of goodwill that erodes once the next assignment cycles in. By day 14, the professor is grading assignment 7 and has no recall of assignment 5.

Evidence That Actually Changes a Grade

Evidence in a regrade request works when it is specific, visual, and directly tied to rubric points. Generic arguments fail. Concrete artifacts succeed. The 4 evidence types below cover almost every regradable situation. Understanding what graders actually measure changes the whole evidence question. How Professors Evaluate Programming Assignments (Beyond Just Output) breaks down the full grading dimensions that professors weight beyond raw correctness.

Rubric citations

A regrade email that quotes the exact rubric wording and points out the scoring mismatch is the single strongest evidence form. A student writing “the rubric states ‘partial credit for working subcomponents,’ my hash table insert function passes all 8 visible tests, and I received 0 out of 5 points for this section” gives the professor a clear path to fix the grade.
Vague references to “the rubric” without quotes fail. Pull the exact language from the rubric document and paste it into the email.

Test case output screenshots

Screenshots of passing test cases from the autograder or from local test runs prove correctness in a way text descriptions do not. A Gradescope screenshot showing 8 out of 10 tests passing, paired with a rubric that awards 80% credit for 80% of tests passing, resolves most regrade disputes in under 10 minutes of TA review.

Screenshots of the terminal or IDE output work for local test cases, especially when the assignment specification included sample inputs and expected outputs. Match the image to the specific rubric line being disputed.

Git commit timestamps and version history

Git commit history resolves 2 specific dispute types: late submission penalties applied to code that was actually finished on time, and claims that a student submitted an incomplete version of the assignment. A git log output showing a final commit 6 hours before the deadline, paired with the repo URL, gives the grader verifiable proof.

Git evidence only works when the course uses version control and the student committed regularly. A single panic commit 2 minutes before the deadline proves nothing. Regular commits across the assignment cycle prove iterative work.

Direct quotes from the assignment specification

The assignment PDF or handout is the contract between the student and the grader. A regrade argument built on a direct quote from the specification is nearly impossible to deny. Example: “The specification states ‘use iteration, not recursion.’ My solution uses iteration, and the grader deducted points for not using recursion.”

Always link the quote to the page number or section of the specification. Professors and TAs trust citations. They distrust paraphrases.

How to Write the Regrade Request Email

The regrade request email works when it is short, specific, unemotional, and structured around evidence. Long emails lose the reader. Emotional emails trigger defensiveness. The template below runs 180 to 220 words and is the exact structure that works across Canvas, Gradescope, and direct email.

The 6-word subject line formula

The subject line formula: “Regrade request: [Assignment name], [specific issue].” Example: “Regrade request: Assignment 4, missing partial credit on test 7.” The structure tells the professor exactly what the email covers before opening it, which reduces the mental load of sorting the inbox.
Avoid vague subject lines like “Question about my grade,” “Quick question,” or “Hi professor.” Those lines get sorted into the low-priority pile and answered last.

The opening frame that avoids defensiveness

Open with context and calm: “I’m writing about Assignment 4, which received a grade of 72 on November 15. After reviewing the rubric and my submission, I found a specific issue I’d like to flag for regrade review.” The frame does 3 things at once: it states the assignment, it states the grade, and it signals that the student reviewed the work before writing.
Opening with “I think my grade is wrong” or “I don’t understand why I got this grade” reads as hostile or unprepared. Opening with “after reviewing the rubric and my submission” reads as diligent.

How to present evidence without sounding accusatory

Present evidence as observation, not accusation. “The rubric awards 5 points for partial credit on working subcomponents. My hash table insert function passes 8 of 10 test cases per the attached Gradescope output, and I received 0 points for this section.” The language stays factual. No “the grader made a mistake,” no “this is unfair,” no “I deserve these points.”
Professors respond to facts. Facts invite correction. Accusations invite pushback.

The specific ask (points, partial credit, or reconsideration)

End the evidence section with a specific ask. Vague asks like “please review my grade” force the professor to guess at what’s being requested. Specific asks like “I’d like to request partial credit review for section 3, specifically the 5 points tied to the hash table insert function” give the professor a clear action item.
The 3 valid ask formats: a specific number of points back, partial credit review for a specific section, or reconsideration of a specific rubric line. Pick one.

Subject: Regrade request: Assignment 4, missing partial credit on test 7

Hi Professor [Name],

I’m writing about Assignment 4, which received a grade of 72 on
November 15. After reviewing the rubric and my submission, I found
a specific issue I’d like to flag for regrade review.

The rubric awards 5 points for partial credit on working subcomponents.
My hash table insert function passes 8 of 10 test cases per the attached
Gradescope output, and I received 0 points for this section. I believe
this was a partial credit oversight.

I’d like to request partial credit review for section 3, specifically
the 5 points tied to the hash table insert function. I’ve attached:
- Screenshot of Gradescope test output
- Screenshot of the relevant rubric line
- Link to my Git commit from November 14 at 8:47 PM

Happy to discuss in office hours if that’s easier. Thanks for your time.

Best,
[Your name]
[Course number and section]
[Student ID if required by the course]

How Gradescope, Canvas, and Blackboard Handle Regrade Requests

The regrade submission process varies by platform, and submitting on the wrong channel delays resolution by days or routes the request to the wrong person.

Gradescope’s built-in regrade request feature

Gradescope has a dedicated regrade request feature on each graded submission. Click the question with the disputed score, click “Request Regrade,” and enter the evidence-based message. The request goes directly to the grader who marked that question, which speeds resolution because the original context is preserved.

Gradescope’s feature has one catch: it locks the window at the instructor’s configured duration, usually 3 to 14 days after the grade is published. Once the window closes, the button disappears, and email to the professor becomes the only option.

Canvas comment-based regrade submissions

Canvas does not have a native regrade feature. Regrade requests go through the Assignment Comments section on the SpeedGrader-linked submission or through direct email to the professor. Canvas Comments route to the instructor and any course-linked TAs, which means the first person to see the comment handles the request.

For Canvas courses, the email approach is often cleaner because it goes directly to the professor without getting intercepted by a TA without authority to change grades.

Blackboard’s grade dispute workflow

Blackboard handles regrades through the Grade Center comments feature, which functions similarly to Canvas Comments, plus a separate “Review Submission” link on some assignment types. The workflow is course-dependent. Some instructors configure a grade review feature. Others route everything to email.

Check the syllabus first and follow whatever regrade mechanism it specifies. Submitting to the wrong channel on Blackboard is the single most common reason regrade requests get ignored.

5 Mistakes That Make Professors Say No

These 5 mistakes turn regrade requests into denied regrade requests, regardless of the merits of the underlying case. Each one triggers a specific professor reaction that kills the request.

Making it personal or emotional

Emotional regrade requests get denied because they signal the request is about feelings, not facts. Phrases like “I’m really stressed about this,” “this grade affects my scholarship,” and “I worked so hard on this” push the professor into a defensive posture. The professor stops reading the technical argument and starts reading the emotional pressure.

Keep personal context out of the email. Personal context belongs in office hours, not in the written request.

Arguing philosophy instead of facts

Arguments about what programming assignments “should” test, what grading “ought to” measure, or what the course “really” means lose 100% of the time. Professors did not write the rubric to be philosophically defensible. They wrote it to measure the specific competencies the course targets.

A regrade request argues against the rubric as applied. It does not argue against the rubric as designed.

Comparing your grade to another student’s

Comparison arguments fail on 2 grounds: they violate academic privacy norms, and they assume the other student’s submission is identical to yours. Professors react to “my friend got a higher grade on similar code” with suspicion about code-sharing, not sympathy about grading inconsistency.

Grade your own submission against the rubric. Other students are irrelevant.

Threatening escalation in the first email

Mentioning the department chair, the dean’s office, or an academic appeal in the first regrade email poisons the entire process. The professor reads the threat as an attack and shifts from “how do I fix this” to “how do I protect myself.” The grade freezes in place.

Escalation has its place, covered in the next section. Not in the first email.

Submitting without specific evidence

A regrade request with no attached screenshots, no rubric quotes, no specific test case references, and no Git commit links is just a complaint. Professors deny vague complaints on sight because there is nothing to verify.

Every regrade request attaches at least 1 piece of specific evidence. No evidence, no request.

What to Do If the Regrade Is Denied

A denied regrade is not the end of the conversation. It is a signal to shift channels. The 4 follow-up paths below cover the escalation ladder from friendliest to most formal.

The office hours follow-up conversation

Office hours is the highest-success-rate follow-up. A 10-minute in-person conversation resolves more regrade disputes than 3 rounds of email. The professor sees the student as a person, the student hears the professor’s reasoning in full context, and small misunderstandings get cleared up without paper trails.

Bring the same evidence from the email. Lead with curiosity: “I wanted to understand the reasoning behind the grade on section 3.” Avoid the phrase “I think you made a mistake.”

Escalating to the course coordinator

Course coordinators handle disputes when the professor and the student reach an impasse and the course has multiple sections. The coordinator reviews both sides and issues a ruling that the professor respects because of departmental norms. This path works best for courses with 200+ students, where a single professor oversees multiple TAs grading inconsistently.

Escalation email format: a 1-paragraph summary of the original regrade request, a 1-paragraph summary of the professor’s denial, and a specific ask for coordinator review. No emotional framing.

Academic appeals committees and when to use them

Academic appeals committees exist at most universities for grade disputes that rise to the level of procedural unfairness. They are the wrong tool for “I disagree with the grade” and the right tool for “the grading policy was applied inconsistently with the syllabus” or “the professor did not follow the documented grading procedure.”

Appeals take weeks. Most appeals fail. Reserve this path for cases with a 10-point or larger grade impact and documented procedural issues.

Knowing when to let it go

Some regrade denials are final, and continuing to push damages the relationship more than the points justify. Signs to stop: the professor has reviewed the submission twice and affirmed the grade, the dispute is over 1 or 2 points, or the evidence is subjective (code style, readability, design choices).
Accepting a denial gracefully often pays off later in the course. Professors remember students who argue well and stop at the right time. They also remember students who do not stop.

How to Avoid Needing a Regrade on the Next Assignment

The best regrade is the one that never happens. 3 specific practices cut regrade need by roughly 70% across most CS courses.

Pre-submission code review

A 30-minute pre-submission review catches the bugs and rubric misses that cause most regrade requests. Run the code against every visible test case, verify the output format matches the specification exactly, and re-read the rubric with the code open in a second window. The common finds: a missing docstring on a graded function, a hardcoded path that breaks on the grader’s machine, or an off-by-one error on an edge case the rubric explicitly tests.
Expert pre-submission review catches issues students miss because they are too close to the code. Autograder-Safe Code: A Simple Checklist for Students covers the technical submission checklist for preventing autograder deductions.

Reading the rubric weights before you code

Most students read the rubric after they finish coding. Reversing that order changes the grade. Reading the rubric first tells the student exactly where the points live: 40% for correctness, 20% for code style, 20% for documentation, 10% for test coverage, 10% for efficiency. Coding to the rubric weights produces higher grades than coding to the problem statement alone.

How to Understand Your Programming Homework: A Simple Guide From An Expert covers the rubric-reading technique in depth, including the common patterns in CS rubrics and how to map code structure to point distribution.

Decoding autograder feedback

Autograder feedback contains exact clues about what the grader is testing. A “timeout on test 8” message points to efficiency issues on large inputs. A “wrong output format on test 3” message points to a missing newline or a print statement difference. Decoding each message before the deadline catches roughly half of all autograder-caused deductions.

Why Testing Matters in Programming Assignments (And How It Improves Your Grades) covers the testing discipline that prevents most autograder surprises, including how to build your own test cases before submission.

When to Get Expert Help Before the Next Deadline

Regrade requests handle the past. Expert pre-submission review handles the future. A CS expert reviewing the code before submission catches rubric misses, autograder issues, and logic gaps that cost points, without the risk of a regrade review turning up new deductions.

MyCodingPal’s coding homework help pairs students with CS experts for pre-submission review, urgent 6-hour debugging support, and full assignment completion when the deadline is unrecoverable. The work comes back with explanations tied to the rubric, which also builds the skills for the next assignment.

Our Work / Samples shows the quality standard and format of past work. For students facing a tight deadline with a grade at stake, expert review is the cleanest way to avoid both bad grades and risky regrade requests.

Frequently Asked Questions

Can my grade go down after a regrade request?

Yes, a regrade triggers a fresh review of the full submission, and graders sometimes find additional deductions on the second pass. Gradescope and Canvas both allow the reviewer to lower grades during regrade. File a regrade request only when the expected gain is at least 5 points and the disputed issue is clearly documented.

How long do I have to request a regrade?

The regrade window varies by platform and instructor, typically 3 to 14 days after the grade is posted. Canvas courses often allow 7 days. Gradescope’s window is set per assignment by the instructor. Blackboard follows course-level syllabus policies. Check the syllabus before writing the email.

Should I email the professor or the TA?

Email the grader listed on the rubric first, which is usually the TA for large courses and the professor for small courses. CC the professor when the grader is a TA and the dispute is substantial (10+ points). Submitting through Gradescope’s built-in regrade feature routes the request automatically to the right person.

What if the assignment specification was genuinely unclear?

Unclear specifications are a legitimate regrade basis when the student asked a clarifying question during office hours or on the course forum before the deadline, and the grading still penalized the ambiguous interpretation. Without that paper trail, the “it was unclear” argument usually fails because the student had the option to ask in advance.

Does requesting a regrade hurt my relationship with the professor?

A well-written regrade request rarely damages the relationship. Professors expect regrade requests and handle them as part of the job. The relationship damage comes from emotional emails, comparisons to other students, and escalation threats in the first message. A factual, evidence-based request reads as professional, not adversarial.