Guide · Any country · Running projects

Freelance project status updates: what to put in them, how often to send them, and emails to copy

A short, regular update tells the client where their project stands before they have to ask: what's done, what's next, what you're waiting for from them, and whether any date is at risk. Here's what to put in one, how often to send it, how to report a problem early, and update emails you can copy.

General information. The update lines, the status labels, the steps, the checklist and the wording to copy are ours (general practice). There's no official rule for how a freelancer reports progress to a client; your contract or statement of work may set one. The research quoted below is about software project managers and students, not freelancers; see Where the sources differ.

The short answer

Agree how often at the start of the project, and send the update on that day even when there's little to say.
Keep the same few lines every time: status, done, next, waiting on you, dates at risk, hours (if they matter) and decisions needed.
Say at risk as soon as you think it, with a reason and what would fix it. Don't wait until you're sure a date will be missed.
Put what you need from the client, with a date, near the top, so it doesn't get lost.
Write it from your tracker, not from memory, and keep the updates in one place as a record.

Want this in a ready-made spreadsheet? Our paid Client & Project Tracker by Small Rows (US$12, one-time) keeps most of an update's raw material in one file: each project's status and due status (Overdue, Due soon or On track), the hours logged against its budget hours with the hours left and the share used, and its open tasks. Tasks can be marked Blocked, and the Follow-ups tab lists next actions with due dates. It doesn't write or send the update: you read the lines off and write the email yourself.

1. Why send updates at all

A client who hears nothing tends to assume either that all is well or that nothing is happening, and neither helps you when a date moves. A regular update lets them plan around the project, gets you their input on time, and means a problem reaches them as news, not as a surprise.

One modelling study suggests that reports on how a project is going can sound better than the project really is. Studying software projects, Snow and Keil (2002) asked "how different is true software project status from reported status?" Their model "uses discrete project status from traffic light reporting", and they concluded that "project managers are overly optimistic in their perceptions" and that "executives should be skeptical of favorable status reports" (Snow and Keil, 2002). That's about managers reporting to executives, not freelancers, but we think a similar caution applies: your own sense of how the job is going may be rosier than it is.

The same optimism shows up in time estimates. Buehler and colleagues (1994) wrote: "The tendency to hold a confident belief that one's own project will proceed as planned, even while knowing that the vast majority of similar projects have run late, has been termed the planning fallacy" (Buehler et al., 1994). An update built from what's actually done, and from the hours you've actually logged, is a check on that.

2. How often to send one

Agree it at kickoff, along with the channel and response times; our onboarding guide's communication norms has the list. If your statement of work sets a reporting schedule, follow that.
Weekly (ours) suits most active projects that run longer than a couple of weeks. Pick a fixed day so the client knows when to expect it.
At each milestone may be enough for a short job; a two-line note when something is ready to look at does the job.
Retainers and ongoing work: a regular summary of what was done and the hours used against the block, on the schedule you agreed.
Send it on the day even when little has changed. A short update that says nothing has moved, and why, is still useful. Silence is what makes clients chase.

3. What to put in an update

Ours (general practice). Keep the same lines in the same order every time, so the client knows where to look. Leave out a line that doesn't apply, such as hours on a fixed-price job where the client doesn't see them.

Line	What to write	Where it comes from in a tracker
Status	On track, at risk or off track, with one plain reason.	Each project's due date and due status, plus your own judgement.
Done since last time	Tasks and milestones finished, in the client's words, not yours.	Tasks you marked done since the last update.
Next	What you'll work on before the next update, with dates for anything the client will see.	Open tasks and their due dates.
Waiting on you	Anything you need from the client (content, feedback, access, a decision) and the date you need it by.	Tasks marked blocked, and your follow-ups list.
Dates at risk	Any milestone or end date that may move, why, and what would keep it.	Tasks or projects that are due soon or overdue.
Hours	For hourly, budgeted or prepaid work: hours used so far against the budget or the block.	Hours logged against the project's budget hours, and hours left.
Decisions needed	Questions only the client can answer, one per line, each with a suggested answer.	Your notes for the project.

Write for someone reading on their phone between meetings: short lines, the client's names for things, and dates as dates rather than as next week.

4. On track, at risk or off track

Snow and Keil's model used traffic-light statuses. A one-word status at the top of each update works the same way for a client: they can see at a glance whether to read on. Our definitions:

Status	What it means	What the update should add
On track	As things stand, the agreed dates, scope and hours will hold.	Nothing extra; keep it short.
At risk	A date, the scope or the hours could slip unless something changes.	What could slip, why, and what would prevent it (often something from the client).
Off track	A date or the hours budget will be missed unless the plan changes.	Options for the client to choose from, and what you need from them to decide.

Use at risk early. It's a heads-up, not an admission of failure, and it gives the client time to help, for example by sending content sooner or agreeing what can wait.
Don't stay on track out of habit. If you've been at risk two weeks running, it may be time to say off track and offer options.
Give the reason in plain words, including when it's on your side.

5. When you're waiting on the client

Put it near the top of the update, with what you need, from whom and by when.
Say what the date protects: which milestone or end date holds if it arrives in time, and that it moves if it doesn't.
Mark the task as blocked in your tracker and add a follow-up for the day after the date you asked for, so you don't forget to chase.
Carry on with other work where you can, and say so.
If it's still not there, send the short waiting-on-you note in section 9. If the delay costs extra time, deal with it the way your agreement says; our scope creep guide covers changes and their wording.

6. When it's running late or over the hours

Tell the client as soon as you know, in the next update or sooner if a decision can't wait.
Lead with the problem, then the reason, then options for them to choose from.
Hours running ahead of the estimate: our estimate guide has an hours update email with options for that case.
A date at risk: the at-risk update in section 9 offers keeping the date with less scope, or keeping the scope with a new date.
Extra work the client asked for is a change, not a slip. Agree it as a change request before you do it, and show the new dates or hours in the next update.

7. Keep the updates in one place

Send updates in writing, in the channel you agreed, even if you also talk on calls. After a call, a short recap of what was decided does the same job.
One thread or one folder per project makes it easy to find what was agreed, and when.
Ask for decisions in writing. A reply saying yes to an option is what you'll point to if the scope or a date is questioned later.
Send to the people the client named in the kickoff, and don't include other clients' details.
If a disagreement does come up, our invoice dispute guide covers what to do; a trail of updates and replies helps there. When the job ends, your last update can feed the handover covered in our wrap-up guide.

8. Writing it from your tracker

Ours. If you keep each project's tasks, due dates and hours in one place, the update is mostly copying:

Update the tracker first: mark finished tasks done, log the week's hours, and mark anything you're waiting for as blocked.
Status: look at the project's due status and the hours left, then decide on track, at risk or off track.
Done and next: copy the tasks you finished, and the open tasks due before the next update.
Waiting on you: copy the blocked tasks and any follow-ups for this client.
Hours: copy hours logged and hours left, if the client sees them.
Add a follow-up in your tracker for the next update's day.

Our project tracking guide shows how to build such a tracker yourself, with a weekly review to copy; the update can be the last step of that review. To log hours, there's our free timesheet.

9. Update emails to copy

Replace everything in [brackets]. These are ours.

Regular (weekly) update

Subject: [project] — update for the week of [date]

Hi [name],

Status: [On track / At risk / Off track] — [one plain reason].

Done since last update:
— [task or milestone, in your client's words]
— [task or milestone]

Next, before [date of next update]:
— [task], ready for you to see by [date]
— [task]

Waiting on you:
— [content / feedback / access / a decision] by [date], so that [what it keeps on schedule].

Dates at risk: [none / which date, why, and what would keep it].

Hours: [hours used] of [budget hours] so far. [Only for hourly, budgeted or prepaid work.]

Decisions needed:
— [question]? I'd suggest [your suggestion], because [reason].

Next update: [day]. Reply any time if something changes on your side.

Thanks,
[your name]

Short update for a small job or a milestone

Subject: [project] — [milestone] done

Hi [name],

[Milestone] is done: [where to see it / link].
Next: [what comes next], by [date].
From you: [feedback on what / nothing for now] by [date].

[your name]

When you're waiting on the client

Subject: [project] — waiting on [what you need]

Hi [name],

A quick note on [project]: I still need [content / feedback / access / a decision on what] to carry on with [task].

If I have it by [date], we're still on track for [milestone or end date]. After that, [milestone or end date] would move by about as long as it takes to arrive.

[If it helps: I can carry on with (other task) in the meantime / a short call could settle it.]

Thanks,
[your name]

When a date is at risk

Subject: [project] — [milestone or end date] is at risk

Hi [name],

I want to flag this early: [milestone or end date] is at risk because [one honest reason, e.g. a task took longer than planned / feedback came later than agreed / something new came up].

Where things stand: [what's done], [what's left].

Options:
— Keep the date by [what you'd drop, simplify or move to a later phase].
— Keep the full scope and move the date to [new date].
— [Another option, if there is one.]

Could you let me know which you'd prefer by [date]? Until then I'll carry on with [the work that doesn't depend on the choice].

Thanks,
[your name]

10. Checklist

How often you'll update, and where, agreed at kickoff.
A fixed day for the update, kept even in quiet weeks.
The same lines every time: status, done, next, waiting on you, dates at risk, hours if they matter, decisions needed.
A status of on track, at risk or off track, with a plain reason.
What you need from the client, with a date, near the top.
Problems reported early, with options.
Changes agreed in writing before the extra work starts.
Tracker updated first, and the update written from it.
Updates and replies kept in one thread or folder per project.

Free tools and kits

How to track multiple client projects: build your own tracker with due status, budget hours and hours left.
Free timesheet template: log the hours behind the update, in your browser.
Our paid Client & Project Tracker by Small Rows (US$12, one-time) keeps most of an update's raw material in one file: each project's status and due status (Overdue, Due soon or On track), the hours logged against its budget hours with the hours left and the share used, and its open tasks. Tasks can be marked Blocked, and the Follow-ups tab lists next actions with due dates. It doesn't write or send the update: you read the lines off and write the email yourself.
Our paid Freelance Billing Kit by Small Rows (US$12, one-time) is for the invoice once the work you've reported is done.
All three kits together: the All-Kits Bundle by Small Rows (US$24, one-time).

Where the sources differ

Who was studied. Snow and Keil (2002) built a model of software project managers reporting to executives, with inputs from a small panel of experts; it isn't a study of freelancers or their clients. Buehler and colleagues (1994) studied students and their own tasks. We didn't find research on freelancers' updates to clients, so the advice on this page is our reading, not a finding.
How we read the papers. For Snow and Keil (2002) we quote only the abstract, taken from the OpenAlex record of the paper, because the publisher's page couldn't be read from our side. The Buehler and colleagues quote comes from the full text of the paper.
How often to update. There's no research-backed best interval that we found; weekly is a common habit, not a rule. What you agree with the client matters more.
What we did not check: research on client satisfaction and communication; project-management standards and their reporting templates; any rules in particular industries or contracts about progress reports.

Sources

Snow, Keil (2002). The challenge of accurate software project status reporting: a two-stage model incorporating status errors and reporting bias. IEEE Transactions on Engineering Management, 49(4), 491–504. doi:10.1109/tem.2002.807290
Buehler, Griffin, Ross (1994). Exploring the "planning fallacy": Why people underestimate their task completion times. Journal of Personality and Social Psychology, 67(3), 366–381. doi:10.1037/0022-3514.67.3.366

Checked 2026-10-24. Found a mistake? Tell us via Support.