Guide

How to Write a Self-Review With Evidence (2026 Guide)

Updated October 2026 · by Jerry Liu, Dayflow's founder

Write it from evidence, not memory. Start from the review rubric, pull proof from your calendar, sent mail, tickets and docs, then turn each item into an outcome with a link. To capture the next cycle, Timing suits billable Mac work, WakaTime suits coding-time metrics, ActivityWatch suits free local logs, and Dayflow writes a readable daily timeline of your work on a Mac.

A good self-review reads like a short case file: here is what I did, here is why it mattered, here is where you can check. The usual one reads like a memory test. You sit down the night before it is due and remember the last three weeks clearly. A spring launch comes back vaguely. The quiet work in between, the incident you handled at 11pm, the doc that unblocked another team, the four candidates you interviewed, is gone.

This guide shows how to write the first kind. The method works with nothing more than your calendar, your inbox and a text file. Tools help with one step, capturing what you do going forward, and we cover four of them. Dayflow is our product, so weigh what we say about it with that in mind. Everything said here about other tools comes from each vendor’s own pages as checked on October 4, 2026. This is a comparison of vendor documentation.

The short version

  1. Get the rubric and the exact review window, and build your doc around the rubric.
  2. Mine the records you already have: calendar, sent mail, chat, tickets, code, docs.
  3. Start capturing your work as it happens, by hand or with a tracker.
  4. Turn each piece of activity into an outcome with a link to the proof.
  5. Pick your strongest stories and map them to the rubric.
  6. Write an honest growth section, then check every claim before you submit.

What you need before you start

Step 1: What is the review actually asking for?

Before you collect anything, read the form. Most self-reviews ask about a handful of dimensions, such as impact, execution, collaboration and growth. Your evidence doc should have one heading per dimension, plus a heading for last cycle’s goals, plus an “unsorted” bucket.

Pin down the window too. “This year” might mean the calendar year, the fiscal year or the time since your last review. If you joined a new team mid-cycle, ask whether the earlier work counts.

Illustration: a review covering April 1 to September 30 with a rubric of “Impact, Craft, Collaboration, Growth.” The doc starts as six empty headings: those four, “Goals from last cycle” and “Unsorted.”

Mistake to avoid: writing a chronological diary. Reviewers score against the rubric, so a month-by-month list forces them to do the sorting for you, and they will sort less generously than you would.

Step 2: Where is the evidence you already have?

Even without any tracker, you are surrounded by records. The job in this step is to collect, not judge. Put everything in the unsorted bucket with a date and a link.

Go through these in order:

Illustration: searching sent mail for “postmortem” between April and September turns up a thread from June where you wrote the incident summary for an outage you were not on call for. That never appeared on any ticket. It goes in the doc with the link.

Mistake to avoid: only counting assigned work. Unassigned work, like helping a new hire, fixing a flaky process or writing the doc nobody owned, is often what separates a strong review from an average one, and it leaves the faintest trail.

Step 3: How do you capture work as it happens?

Step 2 rebuilds the past. It always has gaps, because most of a workday leaves no artifact. The fix is to capture the next cycle as you go. No tool installed today can recover last spring, so if your review is due this week, do this step for next time.

You have two routes.

By hand. Spend two minutes at the end of each day writing what you worked on and anything that changed. The daily work log template gives you the structure. Once a week, roll those entries up into a short summary with the weekly status report template. At review time you read your weekly summaries, not your memory. Our guide to keeping a work journal covers the habit in more detail.

With a tool. An automatic tracker removes the daily writing step. If you are choosing a time tracker for Mac, these four suit self-review evidence in different ways.

Timing (Timing vs Dayflow) records time automatically across apps, websites and documents on your Mac, down to specific URLs and Mail threads, and also takes manual entries. It lists AI activity summaries on all plans. Timing says tracked times stay on your Mac unless you opt into sync. There is no free tier. The Professional plan is $9 per month billed annually or $11 per month billed monthly, with a 30-day trial and no credit card required. Its strengths lean toward billable work: billing status, customizable reports and invoicing integration.

ActivityWatch (ActivityWatch vs Dayflow) is free and open source under MPL-2.0. It records the active application, window title and whether you are away from the keyboard. Browser extensions add tab titles and URLs, and editor plugins add coding activity. All data stays on your device. It does not list built-in AI summaries, so you get accurate raw events and do the interpreting yourself.

WakaTime is for developers. Editor plugins record coding time and AI usage per project, language and editor, and send it to a hosted web dashboard. It only sees what happens in supported editors and terminals. The free plan keeps one week of dashboard history, which is too short for a six-month review. Full history requires Premium, at $14 per month billed monthly or $12.83 per month billed $153.96 yearly.

Dayflow records your screen at one frame every 10 seconds and has AI write the day into a readable timeline. Recordings and the timeline are stored on your Mac. You choose where screenshot analysis happens: Local AI through Ollama or LM Studio keeps it on-device, or you can send selected screenshots to your own cloud provider or use Dayflow Pro. The app is $0 and MIT licensed, with an optional Pro plan at $20 a month, and needs macOS 14 or later. You can export a date range as Markdown from Settings → Export, which gives you a text record of a whole review window to read or search. The export work history workflow walks through it.

Before running any screen-level tool on a work machine, check your employer’s policy. The local and cloud processing page explains which Dayflow mode sends what off your Mac.

Illustration: you install a tracker on October 1. Every Friday you spend ten minutes reading the week’s timeline and copying anything review-worthy into your evidence doc with a date. By March you have half a year of weekly entries instead of a blank page.

Mistake to avoid: collecting data and never reading it. A tracker full of six months of unreviewed activity is almost as hard to use as no record at all. The weekly pass is what turns raw logs into evidence.

Step 4: How do you turn activity into outcomes?

Now sort the unsorted bucket. For each item that matters, write three parts:

  1. What you did. One sentence, active voice, first person.
  2. What changed. The result for the team, the customer or the business. If you do not know, ask someone who would.
  3. Proof. A link to the doc, ticket, pull request, dashboard or thank-you message.

Hours and activity data from step 3 belong in the proof or the context, not the headline. “Spent 40 hours on the migration” describes effort. “Moved billing to the new system with no customer-facing downtime” describes an outcome. The hours can explain why it was hard.

Illustration: your tracker shows that through May you spent a large share of every Monday rebuilding the same weekly report by hand. In June you automated it. The entry reads: “Automated the Monday metrics report, which the team now gets without manual work. I now use that time for planning. Proof: the script repo and the June announcement thread.” If you want to put a number on recurring time like that, the where does my week go calculator helps you estimate it from your own inputs.

Mistake to avoid: claiming team results as solo results. Write “I led,” “I wrote,” “I proposed” for your part, and name the team for theirs. Reviewers usually know who did what, and overclaiming costs more credibility than it gains.

Step 5: Which stories should make the cut?

You will have more entries than space. For each rubric section, choose a few of your strongest, and make the first one the best. The top of each section gets the closest read.

A useful mix per cycle:

If one story fits several sections, put it where it is strongest and reference it briefly elsewhere instead of repeating it.

Illustration: the outage write-up from step 2 goes under Collaboration, not Impact, because its value was that three teams adopted the follow-up checklist. Under Impact you lead with the automated report from step 4.

Mistake to avoid: burying the biggest win in the middle of a long list. If a reviewer reads only the first line of each section, that line should be your best evidence.

Step 6: How do you write the growth section and check your work?

The growth section is where many self-reviews go soft. Pick one real gap, show you noticed it through a specific example, and say what you are already doing about it. Then set two or three goals for next cycle that someone could check in six months.

Then audit. Go through every claim and confirm it has a source you could link. Remove adjectives you cannot back up. If you used AI to summarize your notes or exports, treat that draft as unverified. AI summaries, Dayflow’s included, can miss work or misinterpret what happened, so check outcomes before sharing. If you paste tracker data into a cloud assistant, remember that the conversation is not local even when the original data was.

Illustration: “Two of my three project estimates this cycle slipped by more than a week. Looking at my logs, I underestimated review time each time. Since August I add a review buffer to every estimate and share it with the team. Goal: estimates on next cycle’s projects land within the buffer.”

Mistake to avoid: the disguised strength. “I care too much” reads as evasion. A concrete gap with a plan reads as judgment.

Doing it by hand vs with a tool

None of the tools here is a pure start-stop timer. Timing comes closest, since it takes manual entries alongside automatic tracking.

ApproachEffortWhat you getCost
Manual daily log + weekly summaryTwo minutes a day, ten minutes a weekExactly what you chose to write, already in your words$0
TimingLow daily effort, weekly reviewAutomatic app, website and document time on Mac, AI activity summaries, billing-oriented reportsFrom $9 per month billed annually or $11 per month billed monthly; no free tier; 30-day trial
ActivityWatchLow daily effort, more interpreting at review timeRaw app, window title and away-from-keyboard events stored on your device; no built-in AI summaries listedFree
WakaTimeInstall editor plugins, then nothingCoding time and AI usage per project, language and editor; nothing outside editorsFree plan keeps 1 week of history; Premium for full history is $14 per month billed monthly or $12.83 per month billed $153.96 yearly
DayflowLow daily effort, weekly reviewAI-written readable timeline from screen frames every 10 seconds; Markdown export of any date range$0, MIT licensed; optional Pro at $20 a month

Disclosure again: Dayflow is our product. Check current pricing on each vendor’s site before buying, since plans change. Dayflow’s plans are on the pricing page.

Common mistakes

Where Dayflow is the wrong pick

Dayflow writes a readable record of your Mac day. That is useful for self-reviews, but it is not the right tool for every reader.

The bottom line

A self-review with evidence comes down to two habits: build the document around the rubric, and give every claim a link. For a review due soon, your calendar, sent mail, tickets and docs are enough. For the next one, capture work as it happens, either with a two-minute daily log or an automatic tracker you actually review each week.

Timing is the stronger pick for billable Mac work, WakaTime for coding metrics, and ActivityWatch for free, local, cross-platform logs. Dayflow fits if you want a readable timeline of your whole Mac day and a Markdown export to write from. Whichever you use, the tool gives you raw material. The judgment about what mattered is still yours. If you want more on rebuilding a record of past work, see how to remember what you worked on.

Frequently asked questions

What should I include in a self-review?

Include a few strong accomplishments for each section of your company's rubric, each written as what you did, what changed because of it and where the proof lives. Add one or two pieces of less visible work, such as unblocking another team. Close with an honest growth area backed by an example and two or three specific goals for the next cycle.

How do I write a self-review if I can't remember what I did?

Rebuild the period from records that already exist. Scroll your calendar week by week, search your sent mail and chat for threads you started, list tickets you closed, pull requests you merged and documents you authored. Those sources jog memory far better than a blank page. Then start a daily log or tracker now so the next review is easier.

Should I put hours worked in my self-review?

Usually not as a headline. Hours show effort, not results, and a reviewer cares about what changed. Time data is useful as supporting evidence, for example showing that a recurring task took a large share of your week before you automated it. Use hours to explain a decision or a tradeoff, then lead with the outcome.

Can I use AI to write my self-review?

AI is useful for summarizing your own notes, exports and logs into a first draft, but treat that draft as unverified. AI summaries can miss work or misread what happened, and they tend toward generic phrasing. Check every claim against a source you can link, rewrite in your own voice and confirm your employer allows the data you paste into a cloud assistant.

What is the best tool to show coding work in a self-review?

For coding specifically, WakaTime beats Dayflow. Its editor plugins record coding time per project, language and editor, and it tracks AI coding usage. Dayflow records your whole screen and writes a general timeline, which is broader but less precise about code. Note that WakaTime's free plan keeps one week of dashboard history; full history requires the Premium plan.

Is it OK to run a screen recording app on a work computer?

Check your employer's acceptable use and data policies first, since your screen will show confidential material. If it is allowed, prefer tools that store data locally. Dayflow keeps recordings and the timeline on your Mac, and its Local AI mode keeps screenshot analysis on-device. Cloud modes send selected screenshots off the machine, so read the terms before choosing one.

How do I write about weaknesses in a self-review?

Pick one real gap, show you noticed it through a specific example, and describe what you are already doing about it. For instance, say that estimates on two projects slipped, explain the pattern you found and name the change you made. A concrete weakness with a plan reads as judgment. A vague one, or a disguised strength, reads as evasion.

Does Dayflow work on Windows or Linux?

No. Dayflow is Mac only and needs macOS 14 or later. If you work on Windows or Linux, ActivityWatch is a free, open source alternative that runs on Windows, Mac, Linux and Android and stores data on your own device. It records active apps, window titles and away-from-keyboard time, though it does not list built-in AI summaries.

Can a time tracker help with a review that is due this week?

Only partly. Trackers record from the moment you install them, so a tool started today cannot recover the months already behind you. For a review due soon, rely on your calendar, mail, tickets and documents. Start the tracker or a daily log now anyway, so the next cycle has a complete record instead of a reconstruction.

See where your day actually went

Dayflow is $0 and open source. Full recordings stay on your Mac, with local AI available for on-device analysis.

Download for MacOS macOS 14+ · MIT licensed · no account required