How to Reconstruct a Workday When You Forgot to Start a Timer

Forgetting to start a timer does not mean you should fill an invoice from memory. It means you need to reconstruct the day carefully, with a record that shows what you know, what needs context, and what you cannot support.

The goal is not to make every minute look productive or billable. The goal is to produce a chronological draft you can review. That draft is much more useful than an app total or a vague recollection at the end of the week.

1. Define the boundary before you inspect the day

Start with the date, your working window, and the client work that could reasonably fall inside it. List the active clients, projects, and tasks for that day before looking at browser history, commits, messages, notes, or computer activity.

This simple order matters. If you begin with a long list of apps and tabs, it is easy to attach activity to the wrong client after the fact. A browser session could be research for one project, a support investigation for another, or a personal interruption. The surrounding task determines its meaning.

Create a short reconstruction sheet with these fields:

• date and approximate working window;
• client and project candidates;
• known meetings, calls, or planned tasks;
• work segments you can support;
• ambiguous intervals that need more context;
• breaks, personal time, and unknown time.

Do not force the day to add up to a target number of hours. An unaccounted-for interval is a valid result.

2. Build a timeline from context, not from app totals

Work forward through the day and collect signals in time order. Useful context can include calendar entries, task notes, Git activity, files or project directories, terminal and IDE activity, agent sessions, and the sequence of windows or domains you used. Each signal is a clue, not a conclusion.

Write a plain timeline first. For example:

Illustrative reconstruction

09:10-09:35: reviewed a client brief and project notes.

09:35-10:40: worked in the project repository; a commit and task notes point to a bug investigation.

10:40-11:15: unclear browser and messaging activity.

11:15-12:00: prepared a response connected to the same bug investigation.

12:00-13:00: lunch and no work context.

Notice what this draft does not say. It does not label every browser minute as research. It does not call the unclear interval billable simply because the computer was in use. It records the evidence that exists, then leaves room for review.

If you use LogAgent, it can automatically collect signals including active windows, domains, project directories, Git, IDE or terminal activity, AFK, focus sessions, context switches, and breaks. That can give you a starting timeline, but you still need to interpret the segments against your actual project and task context.

3. Classify each interval before assigning it to a client

Once the timeline exists, give every interval one of four labels:

1. Supported work: The project and task are clear from more than one piece of context, such as a task note plus a commit, meeting, or project directory.
2. Work with context needed: The activity may belong to a project, but the record is incomplete. Look for a note, message, deliverable, or follow-up action before allocating it.
3. Break or non-client time: Mark it separately. A gap is not evidence of work.
4. Unknown: Keep this label when the available record cannot establish what happened.

Then add client and task attribution only to segments you can explain. If an interval includes a real transition between two projects, split it only when you have a reasonable basis for doing so. Otherwise, leave the transition unresolved or record it as administrative time according to your own agreed billing practice.

This is also where memory can help, but memory should test the record rather than replace it. You might remember that the morning bug investigation followed a client call. Check whether the call, task, repository activity, and resulting note fit that account. If they do not, revise the timeline instead of making the evidence fit the story.

4. Review the record as evidence, not as an invoice

Before using the reconstruction in a time report or invoice, ask four questions:

• Can I name the client, project, and task for this segment?
• What context supports that attribution?
• Is this a work record, or am I also assuming it is billable?
• Would I be able to explain the entry in a short, factual sentence?

A useful final entry might read: “Investigated payment-service error for Project A, including repository review and follow-up response.” It names the work without claiming more certainty than the record provides.

LogAgent can group activity segments into projects, clients, and rates, and its invoice lines include billability rationale and provenance. Those records are still material for review, especially where a segment is mixed, disputed, or short on context.

The practical checklist is simple: define the boundary, build the day in order, label uncertainty honestly, add project context, and review each supported segment before it reaches a client-facing record. A reconstructed day does not need to be perfect. It needs to make its limits visible.