What to Log and What Not To
The time entry is read by somebody months later with a question. What makes it answer them.
A work diary entry takes ten seconds and is the evidence that actually gets used. Most are written as though nobody will read them, and then somebody does.
The issue in “What to Log and What Not To” becomes easier to manage when the record and its limits are explicit. A team reviewing visit the official site for time tracking with screenshots should choose only the necessary evidence, explain how it will be used and keep a human correction path open.
What a useful entry contains
What you were working on, specifically.
For an independent reference relevant to “What to Log and What Not To”, consult the European Data Protection Board guidelines; compare its principles with the proposed contract, collection, access model and real review process.
What moved, where there is something to say.
Enough that a stranger could connect it to a deliverable.
"Drafting section 4 of the integration spec" rather than "development", which is the whole difference.
Why specificity matters more here than anywhere
Frames are ambiguous; the diary is the only text.
In a dispute it is what the platform reads first, and it is what the client reads when checking an invoice.
A month of entries saying "work" is indistinguishable from a month of entries saying nothing.
What not to put in
Other clients' names or project details.
Anything confidential belonging to a third party.
Personal matters, which do not belong in a billing record.
And frustration about the client, which reads badly later and is never useful.
The level of detail
Enough to identify the task, not enough to leak anything.
"Fixing the import failure reported Tuesday" is good.
"Fixing the import failure for [other client's system name]" is a breach.
One rereading before submitting catches this, and it is worth the habit.
Timing
At the time, or at the end of the block.
Reconstructed entries drift toward the generic, which defeats the purpose.
And on most platforms a late diary entry is weaker evidence than a contemporaneous one.
Your own parallel record
One line per block, in your own file: what it was, what moved, anything unusual.
More candid than the platform entry and entirely yours.
This is the record that answers queries months later, and it survives account problems.
For the client reading them
Diary entries are more informative than frames and take a fraction of the time.
If you review anything, review these.
And if they are consistently uninformative, ask for better ones rather than looking at screenshots — it is a reasonable request and it improves the record for both.
The honest limit
A diary proves what somebody says they did.
Paired with an artefact — a commit, a document version, a delivered file — it becomes considerably stronger.
Neither alone is proof; together they are the best available, which the evidence section develops.
What to check
Could a stranger read last week's entries and say what you did?
Is anything confidential in them?
Are they written at the time?
And do you keep a parallel record of your own?