When a technical problem may affect an assignment, contact the instructor as soon as the risk is clear. The message should make the situation easy to understand: identify the course and assignment, describe what happened, state what you have checked, explain the current risk, and make one specific request.
You do not need to prove the final cause before sending the first message. You do need to be accurate about what you observed and what you have tried.
Use the syllabus as the first authority
Read the assignment instructions, submission rules, late policy, and course communication instructions before writing. Those documents—not a general internet template—determine what options are available.
If the syllabus says to use a particular submission system or contact channel, follow that instruction. If the policy is unclear, ask a focused question rather than assuming that a technical problem automatically creates an extension.
Write the message around evidence
Use this structure:
Subject: Technical problem affecting [assignment] — [specific request]
Hello [Instructor name],
I am writing about [course and assignment], due [date and time].
At [time], I observed [specific symptom]. The last known good state was
[brief description]. I have [safe actions already taken], and I have preserved
[incident log, screenshot, submission receipt, or other safe evidence].
The current risk is [what may not be possible by the deadline]. I am requesting
[one specific question or request]. I can provide [relevant evidence] if useful.
I will continue [safe recovery or submission step] and will update you by
[time or event] if the situation changes.
Thank you,
[Name]
The template is a starting structure, not a script. Remove any sentence that is not true for your situation.
Choose the scenario that matches the evidence
The request changes with the failure. Keep the message short, but name the part of the course workflow that is blocked.
LMS outage
Use this when the assignment is ready or nearly ready but the required submission path is unavailable:
Subject: CS 101 Project 2 — LMS submission unavailable
Hello Professor Lee,
Project 2 is due today at 11:59 p.m. At 10:42 p.m., the LMS returned an
“upload failed” message after I selected the final PDF. I saved the PDF locally,
kept the submission screen and error timestamp, and have not changed the file.
Would you prefer that I send the PDF through the course-approved email channel
now, or should I continue trying the LMS and update you if it becomes available?
Thank you,
Sam
Hardware crash
Use this when the computer or storage device is unstable and repeated attempts could cause more damage:
Subject: DATA 210 Lab 4 — hardware problem before submission
Hello Professor Lee,
My laptop shut down repeatedly at about 7:15 p.m. while I was preparing Lab 4,
which is due tomorrow at 9:00 a.m. The project folder was present before the
shutdown, but I have not been able to open it reliably since. I stopped making
further changes, recorded the symptoms, and am checking a separate recovery copy.
Could you confirm whether I should submit the last verified export through the
course channel while I seek hardware support?
Thank you,
Sam
Git corruption or lost history
Use this when the working branch changed but the repository may still contain a candidate version:
Subject: CS 220 Assignment 3 — Git recovery in progress
Hello Professor Lee,
After a branch reset at 8:20 p.m., Assignment 3 no longer showed the latest
function in my working copy. I preserved the repository, recorded the current
commit, and found a prior local reference that I am inspecting in a separate
recovery branch. I cannot yet confirm that the recovered version is complete.
Would you prefer a submission of the last verified export by the deadline, or
should I send the recovery result when the comparison is complete?
Thank you,
Sam
These examples describe observations and requests; they do not promise that the instructor will grant an extension or accept an alternate channel. The syllabus and the instructor’s response remain authoritative.
Describe the symptom, not an unsupported cause
Compare these statements:
The hard drive destroyed my assignment.
The document was present at 8:10 p.m. When I opened it at 8:25 p.m., the editor reported that it could not read the file. I have not overwritten the original and am checking the available recovery copies.
The second statement gives an instructor useful information without claiming more than the evidence supports. If you later confirm a cause, send an update with the new evidence.
The reproducible bug-report article explains how to record environment, steps, expected behavior, actual behavior, and errors. A crisis message is shorter: it gives enough context for a decision and points to the fuller evidence if needed.
Make one specific request
Weak requests make the recipient guess what action you want:
Please help. Everything broke.
Stronger requests identify the decision:
Would you prefer that I submit the recovered draft now and replace it later, or should I wait while I complete the recovery check?
May I submit the file through the course email while the LMS upload problem is investigated?
Could you confirm whether the late-submission policy applies while I continue recovering the project?
An instructor may choose a different solution. Your job is to provide accurate facts and a clear question, not to decide the outcome in the email.
Share evidence safely
Useful evidence may include:
- a submission receipt or timestamp;
- the exact error text;
- a redacted screenshot;
- a short incident log;
- a Git commit identifier;
- a file listing or recovery result; and
- a copy of the file requested by the instructor.
Before attaching anything, remove passwords, access tokens, private repository contents, other students’ information, personal identifiers, and unrelated course material. Never send a private key or recovery code as proof of a technical problem.
Make the redaction a small, reviewable workflow:
- Keep the original log or screenshot private and unchanged.
- Make a copy for sharing; do not edit the only evidence.
- Remove credentials, recovery codes, private URLs, student identifiers, and unrelated course content.
- Keep the timestamp, command name, exit status, relevant error text, and enough context to understand the symptom.
- Reopen or inspect the redacted copy before sending it through the course-approved channel.
For example, do not share a line like this:
fatal: could not read Username for 'https://student:EXAMPLE_TOKEN@github.com/course/project.git'
Use a redacted version that preserves the failure but removes credentials and private destination details:
fatal: could not read credentials for '[private repository removed]'
Do not rely on a quick black rectangle over a screenshot without checking the exported result. The recipient needs the error and its timing, not the secret that happened to appear beside it.
If the instructor needs the original file or repository, use the course-approved channel and follow the course collaboration and privacy rules.
Send an update when the facts change
The first message can be sent while recovery is still underway. Follow up when there is a material change: you recover a usable file, submit through an alternate approved channel, confirm that the LMS is working, or learn that the original remains unavailable. State what changed and what you are asking the instructor to decide now. Do not resend the entire story unless new evidence requires it.
For example:
Update: I recovered the version from the 8:05 p.m. Git commit, checked the
required files, and submitted the PDF through the LMS at 11:18 p.m. The receipt
number is [course-approved reference]. The earlier corrupted working copy is
still preserved separately.
This closes the communication loop without overstating what the recovery proved. Keep the sent message, response, receipt, and final version together with the incident record.
Keep a record of the message and follow-up
Save the sent message and record:
- when you sent it;
- which evidence you included;
- the request you made;
- the response and any deadline or submission instructions; and
- the next action you agreed to take.
Do not send repeated messages that add no new information. Send an update when the evidence or situation changes: for example, when you recover a usable copy, submit an alternative file, or confirm that the original is still unavailable.
Common mistakes
- Waiting until after the deadline when the risk was already known.
- Claiming a diagnosis after one failed attempt.
- Attaching a complete private repository unnecessarily.
- Asking for “an extension” without identifying the assignment or policy question.
- Omitting the action you are taking to recover or submit the work.
- Writing an emotional explanation so long that the actual request is hidden.
Do this now
Using a fictional incident, write a five-sentence message: course and deadline, observed symptom, safe actions, current risk, and one request. Then remove every detail that is not needed for the instructor to make the next decision.
Log what you learned
Record which facts were observations, which statements were hypotheses, what evidence you shared, and what response or next action remains. If you used an AI assistant to improve wording, verify every factual sentence yourself before sending the message.