# How to keep a work log

A work log is a short, dated note you write at the end of each work session: what you did, what you decided and what comes next. Next week it tells you where you stopped, and at review time it shows what you got done.

Updated 4 November 2026

## At a glance

- **Takes:** Two minutes, at the end of a session.
- **Write:** Four lines: Done, Decided, Stuck on, Next.
- **Keep:** One log per project, the newest entry last.
- **Read it:** Before you start again, and for ten minutes on Friday.

## What a work log is

A record of what you did and decided, in the order it happened, with the next step at the end.

It isn’t a timesheet. You don’t log hours; if you bill time, keep a time tracker alongside it.

## A work log template in four lines

Copy this into each new entry and delete the lines you don’t need.

Work log template:

```
Done:
Decided (and why):
Stuck on:
Next:
```

Put the date at the top if your tool doesn’t add it. There’s no line for the project, because each project gets a log of its own.

A filled-in entry, from a developer’s log:

Example entry:

```
Done: product search answers in 120 ms on staging; tests pass.
Decided: index titles only for now, because full text doubles the index.
Stuck on: “Müller” doesn’t match “Muller”.
Next: try the accent filter on the staging index.
```

## Write it before you switch

The best moment is right before you move to something else, while the detail is still in your head. By evening you remember what you did, but not what you were about to try, and Next is the line you need on Monday morning. More on coming back: [how to resume a project after a break](https://thread.page/guides/resuming-a-project.md).

One sentence is enough: “Stopped here: the migration runs on staging; next, the two failing reports.”

## One log per project

A single log for everything turns into a list where three projects interleave. Keep one per project, so each reads as one story and its last entry is always where that project starts again.

If you work on one project at a time, one daily log is enough. With several, a short entry in a separate “Week” log can list what moved in each.

## Add a new entry, keep the old ones

When a decision changes, write a new entry that says so and why. When someone asks in March why you dropped the second payment provider, the answer is there with its date, next to what you knew at the time.

## The weekly review

On Friday, read the week’s last entries in each project and write three lines:

Weekly review template:

```
Shipped:
Learned:
Next week:
```

Those three lines are your status update. Over a year they add up to a record of your work for a performance review or a [brag document](https://thread.page/use-cases/brag-doc.md). In nearly 12,000 diary entries from 238 employees in seven companies, Teresa Amabile and Steven Kramer found that progress in meaningful work, even in small steps, mattered more to people’s days at work than anything else ([The Progress Principle](https://www.hbs.edu/faculty/Pages/item.aspx?num=40692)).

## A thread, over time

Your workspace starts empty.

### Billing migration

Work · Waiting

#### Mon 26 Oct

*Written before moving to the next project.*

**You** · 17:40

Done: copied production data to staging. Decided: invoices first, because the reports depend on them. Next: run the migration on staging.

#### Tue 27 Oct

*Stuck on is the line you need tomorrow.*

**You** · 18:05

Done: the migration ran. Stuck on: the invoice and revenue reports show different totals. Next: compare the two report queries.

#### Wed 28 Oct

*A decision, with its reason. Waiting*

**You** · 16:20

Decided: run old and new billing side by side for one cycle, because finance wants to compare the invoices. Stuck on: waiting for finance.

#### Fri 30 Oct

*Friday’s three lines.*

**You** · 17:55

Shipped: the staging migration. Learned: the revenue report counts refunds twice. Next week: production, once finance agrees.

## Where to keep it

- A paper notebook is fast and private. You can’t search it or link to a pull request.
- A spreadsheet suits hours and dates. Decisions and their reasons don’t fit in a cell, so they end up somewhere else.
- One long document works for a while. Then it gets slow to scroll, and it’s easy to type over last week’s entry.
- A notes app with folders keeps entries apart, but you open them one by one to see where a project stands.
- A thread of notes per project keeps its entries together, dated and in order. That’s what ThreadPage is for. It’s free in your browser with no account, and on Free the log stays in that browser, so export a backup now and then. With Pro, a Claude Code or Codex session can add its own entry: [hand a task from one session to the next](https://thread.page/use-cases/agent-work-log.md).

Claude Code and Codex are the names of their owners. ThreadPage is independent and not affiliated with or endorsed by them.

## Questions

### What’s the difference between a work log and a work journal?

Mostly the name. A work log tends to be short and factual; a work journal leaves more room for reflection. The template works for both.

### How long should an entry be?

As short as it can be while you’d still understand it in a month. Two to five lines is typical.

### One entry a day, or one per session?

One per session if you switch projects during the day; a day spent on one project needs one entry.

### Should I share my work log with my manager?

Share the weekly three lines, and keep the raw log for yourself.

### Is a work log the same as a timesheet?

No. A timesheet records hours. A work log records what happened, what you decided and what’s next.

## Start with one thread.

[Start a thread](https://thread.page/app)

Free in your browser. No account needed to start.

Read next

### [Five streams at once, each where you left it](https://thread.page/use-cases/project-notes.md)

Before you switch, one line: stopped here, next. When you come back, the thread’s last note says where to start.

Free · nothing to set up

### [The brag doc your repository helps write](https://thread.page/use-cases/brag-doc.md)

Your repository’s pull requests file themselves into a thread of their own. You note what git can’t see, and at review time your agent drafts from both.

Pro · pull requests and agents

[How to resume a project after a break](https://thread.page/guides/resuming-a-project.md)

[All use cases](https://thread.page/use-cases.md)
