How to Estimate How Long Tasks Take Using Your Own History (2026 Guide)

Write an estimate before each task, record how long it actually took, and compare the two as a ratio for each type of task. Toggl suits you if you will start timers. Timing (Mac, paid) and ActivityWatch (free, open source) record app activity automatically. Dayflow, our free Mac app, records the screen and writes a readable timeline you can check estimates against.

You want to say “that will take about three hours” and have it turn out roughly true. Most estimates fail in a predictable way. You picture the work itself and leave out the setup, the review, the Slack thread in the middle and the second pass. When the task finishes, nobody writes down how long it actually took. The next estimate comes from the same memory that got the last one wrong.

The fix is dull and needs no special software. Write the estimate down, record what actually happened, compare the two, and estimate the next similar task from that record rather than from feel. This guide walks through each step and shows where a tool can do the tedious part.

Dayflow, which appears below as one way to handle the recording step, is our product. For the other tools, this guide compares vendor documentation as checked on October 4, 2026. For Dayflow it uses version 2.2.0. Prices and features change, so check the linked pages before you pay for anything.

The short version

1. Pick three to five kinds of task you estimate again and again.
2. Write an estimate down before each one starts.
3. Record how long the task actually took, by hand or with a tracker.
4. Compare the estimate and the actual as a ratio, task by task.
5. Keep a small reference table of actuals for each task type.
6. Estimate new work from that table, and review it each week.

What you need before you start

• A place to log estimates. A spreadsheet, a notes file or a paper notebook all work. You need columns for date, task, task type, estimate and actual.
• A way to capture actual time. You can write start and end times by hand, run a timer app, or let an automatic tracker record in the background. Step 3 covers the options.
• A couple of weeks of ordinary work. The method only gets useful once you have several finished tasks of the same type to look back on.
• Honesty about the first estimate. Write the number you actually believe, not the number you would tell a client.

If you are curious how your sense of time compares with a clock before you start, the time estimation test is a short exercise for that. It is not a diagnostic, just a quick way to see whether you tend to run fast or slow.

Step 1: Which tasks are worth estimating?

Pick the work you estimate often and where being wrong costs something: missed deadlines, late evenings, or quotes that come in under the real effort. Name each type specifically enough that two tasks with the same label really are comparable.

Illustration: a freelance developer might choose “small bug fix,” “new API endpoint,” “client call plus follow-up notes” and “code review.” A writer might choose “first draft, 1,500 words,” “edit pass” and “research for a new topic.”

Mistake to avoid: making the categories too broad. “Development” or “writing” will mix an hour of work with a week of work, and the range you get back will be useless. If two tasks under one label feel very different, split the label.

Step 2: Write the estimate down before you start

Before you touch the task, write down your estimate in minutes or hours, along with the date and the task type. A single number is fine. If you genuinely don’t know, write a range (“90 to 150 minutes”) and keep the midpoint as the estimate.

The daily work log template has room for this, and you can add an “estimate” column next to each entry.

Illustration: “Oct 6, new API endpoint (invoice export), estimate 3h.” That line takes ten seconds to write and becomes the baseline you check against later.

Mistake to avoid: writing the estimate after you have started, or quietly revising it once the task is half done. An estimate made with hindsight teaches you nothing. If the scope really changes, log a new estimate as a separate line and keep the original.

Step 3: How do you record how long a task really took?

This is the step where most attempts fall apart, because people forget. You have three ways to do it, and the right one depends on how much discipline you want to spend.

By hand. Write the start time when you begin and the end time when you stop. Add a line every time you leave the task and come back. This is free and works anywhere, but a missed entry means a missing data point, and interruptions are exactly what people forget to note.

With a timer app. Toggl (formerly Toggl Track) is the familiar example (Toggl for Mac compared). It centers on manual and real-time timers, timesheets and calendar integrations, and the vendor also lists automated background tracking and a timeline in the desktop app. It runs on web, Mac, Windows, iOS, Android and browser extensions, and the data syncs through the cloud. A timer gives you clean numbers per task if you start and stop it reliably. If you forget, you edit the entry afterward from memory, which puts you back where you started.

With an automatic tracker. These record your activity in the background, so you assign task names afterward instead of remembering to press start. Among the Mac time trackers worth looking at for this:

• Timing (Timing alternative comparison) records time automatically across apps, websites and documents on the Mac, down to specific URLs and Mail threads. The vendor says tracked times stay on your Mac unless you opt into sync. It is Mac-only and paid, with a 30-day trial.
• Rize (Rize alternative comparison) tracks apps and websites automatically and uses AI to categorize and tag them. It runs on Mac and Windows, and the vendor says data is hosted on Amazon Web Services. There is a 7-day trial and no permanently free tier.
• ActivityWatch (ActivityWatch vs Dayflow) 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. It is free, open source under MPL-2.0, and stores data on your own device.
• Dayflow records the screen at one frame every 10 seconds and has AI write the day into a readable timeline. You can run the analysis with a local model through Ollama or LM Studio, send selected screenshots to a provider you configure, or use Dayflow Pro. Full recordings and the timeline are stored on your Mac.

If the general idea is new to you, what an automatic time tracker is covers the basics.

Illustration: you estimated 3 hours for the invoice export endpoint. At the end of the day you open your tracker and see the work split across a morning block, a stretch after lunch and a short fix late in the afternoon. You add the three blocks together and log the actual time.

Mistake to avoid: logging only the main block. The late-afternoon fix and the twenty minutes reading the old code before you started are part of the task. Leaving them out is exactly why estimates keep coming in short. An automatic record helps here because it shows the scattered pieces you would not remember. For more on reconstructing a day after the fact, see how to remember what you worked on.

Step 4: How do you compare estimates with actual time?

For each finished task, divide the actual time by the estimate. That ratio is more useful than the difference in minutes, because it lets you compare a 30-minute task with a 6-hour one.

• A ratio of 1.0 means you were right.
• Above 1.0 means the task ran long. A ratio of 1.5 means it took half again as long as you thought.
• Below 1.0 means you overestimated.

Illustration (made-up numbers to show the arithmetic):

Task	Type	Estimate	Actual	Ratio
Invoice export endpoint	New API endpoint	3h	4h 30m	1.5
Fix date parsing bug	Small bug fix	30m	25m	0.83
Webhook retry endpoint	New API endpoint	2h	3h 20m	1.67
Review PR #212	Code review	45m	40m	0.89

You don’t need many rows before you can see whether a task type keeps running over or stays close.

Mistake to avoid: averaging the ratios when one task blew up. A single task that took four times as long because a dependency broke will drag the average up and make every later estimate too long. Use the middle value (the median) for each task type, and note the outlier separately with the reason.

Step 5: Build a reference table from your actuals

Once a task type has a few entries, summarize it in one row. Record the number of entries, the shortest actual, the median actual and the longest actual. This table is your estimating tool from now on. It replaces “I think it’s about two hours” with “the last ones took between X and Y.”

Illustration:

Task type	Entries	Shortest	Median	Longest	Median ratio
New API endpoint	5	2h 50m	3h 40m	5h 10m	1.5
Small bug fix	7	15m	35m	1h 30m	0.9
Code review	6	25m	45m	1h 10m	1.0

These numbers are invented for the example. Yours will look different, and that is the point.

Mistake to avoid: never updating the table. Your work, tools and codebase change. Add each new finished task, and if a task type’s recent entries drift away from older ones, give more weight to the recent ones.

Step 6: Estimate from the table, then review it weekly

For a new task, find its type in the table and start from the median actual, not from your first instinct. If the work looks bigger or smaller than usual, adjust from there. When the range for a type is wide, give a range rather than a single number: “between 3 and 5 hours, probably closer to 4.”

If a task type has a steady median ratio, you can also use it as a correction. If your new API endpoints run about 1.5 times your gut estimate, multiply the gut number by 1.5.

Then set a short weekly review. Fill in any missing actuals, add the week’s tasks to the table, and look at which types were off and why. A weekly review habit like the one in the deep work review is a natural place to do it. If you suspect the misses come from time leaking into meetings and switching rather than the tasks themselves, where your time goes on a Mac is the next thing to read.

Illustration: someone asks how long a new CSV import endpoint will take. Your gut says 2.5 hours. The table says new endpoints have a median of 3h 40m and a median ratio of 1.5. You answer “about 4 hours, possibly 5,” and you log 4h as the estimate so the comparison stays honest.

Mistake to avoid: applying one correction factor to everything. Your history will probably show that you are accurate on some kinds of work and far off on others, often anything that depends on another person or team. Keep the correction per task type.

Doing it by hand vs with a tool

Approach	Effort	What you get	Cost
Manual log (spreadsheet or notebook)	High. You write every start, stop and interruption as it happens	Exactly what you remembered to write down	Free
Toggl (timer-based)	Medium. You start and stop timers per task; the vendor also lists background tracking in the desktop app	Clean per-task durations when timers are used reliably, plus reports	Free plan for up to 3 users; Starter $9 per user per month billed annually or $12 billed monthly; Premium $16 per user per month billed annually or $24 billed monthly; 30-day trial on paid plans
Timing (automatic, Mac)	Low to record, medium to assign. You turn recorded app, site and document time into entries	Detailed per-app, URL and document history stored locally unless you sync	No free tier; Professional $9 per month billed annually or $11 billed monthly; Expert $11 billed annually or $14 billed monthly; 30-day trial
Rize (automatic, Mac and Windows)	Low to record. AI categorizes and tags activity	App and website time with AI categories, stored in the cloud	No free tier; Basic $9.99/mo billed annually or $12.99/month billed monthly; 7-day trial
ActivityWatch (automatic, open source)	Low to record, medium to interpret. You read app and window-title data	Active app, window titles, away-from-keyboard time and optional URLs, all stored locally	Free
Dayflow (automatic, Mac)	Low to record, low to medium to check. You read a written timeline and confirm the task boundaries	A readable timeline of your day from screen frames every 10 seconds, exportable as Markdown	$0 (MIT license); optional Pro at $20 a month

Again, Dayflow is our product. It is Mac-only and needs macOS 14 or later. It records full-screen frames, keeps recordings and the timeline on your Mac, and leaves the choice of AI processing to you: local AI, your own provider, or Dayflow Pro. Exporting a date range as Markdown from Settings → Export gives you a text record to work from when you fill in actuals. The details are on how local and cloud processing work.

Common mistakes

• Estimating after starting. Once you are into the work, the estimate drifts toward what you already know. Write it first.
• Counting only focused time. Context loading, waiting on review and the follow-up fix are part of the task. If you leave them out, your history will repeat your original optimism back to you.
• Treating an automatic record as the answer. Trackers record activity, not intent. Twenty minutes in a browser might be research for the task or might be something else. Someone still has to decide which blocks belong to which task.
• Trusting AI summaries without checking. Any tool that has AI describe your activity can mislabel work. That includes Dayflow, whose summaries can miss or misinterpret what you were doing. Check the boundaries before you log an actual.
• Throwing out the bad weeks. Weeks full of interruptions are real data. Note why they were bad, but keep them in the table, or your reference ranges will describe a calmer job than the one you have.
• Tracking everything. You only need history for the task types you estimate. Logging every minute of the day is a different project. If that is what you want, the where does my week go calculator is a lighter starting point.

Where Dayflow is the wrong pick

Dayflow fits one part of this method: building a record of what you actually did without pressing start and stop. For several readers, another tool is the better choice.

• Your estimates feed quotes, invoices or team planning. Dayflow has no invoicing, billable rates, team reports or payroll approvals. Toggl wins here, with billable rates on paid plans, profitability reports and timesheet approvals on Premium, plus project planning with capacity management. Timing is the Mac-only alternative, with billing status tracking, report rounding and GrandTotal invoicing integration depending on the plan.
• You want exact per-app durations rather than a written timeline. Timing records down to specific URLs and Mail threads. ActivityWatch records the active window title continuously. Dayflow works from frames every 10 seconds and writes a summary, which is easier to read but is not a stopwatch.
• You are on Windows or Linux, or on a Mac older than macOS 14. Dayflow will not run. ActivityWatch covers Windows, Mac, Linux and Android. Rize covers Mac and Windows and lists macOS Mojave 10.14.6 or later.
• You don’t want your screen captured at all. ActivityWatch records app and window data rather than the screen, and keeps it on your device. Toggl states it does not take screenshots or record keystrokes.
• You want something to block distracting sites while you work. Dayflow has no website blocking. None of the tools in this guide list blocking either, so you would need a separate app.

If you are deciding more broadly, the full list of time tracker for Mac options is a better place to start than this guide.

The bottom line

Estimating well is a record-keeping habit, not a talent. Write the estimate down first, capture the real time including the scattered pieces, compare the two as a ratio, and estimate the next task of that type from its median. A spreadsheet is enough to do all of it.

Tools only change how much effort the recording step takes. Toggl works if you will reliably start timers and need billing. Timing is the paid Mac option with detailed local records. ActivityWatch is the free, open-source, cross-platform option. Dayflow is a free Mac option that writes your day into a timeline you can check estimates against. Pick whichever one you will actually keep running, because the method only works on data you have.

Frequently asked questions

How do I get better at estimating how long tasks take?

Stop estimating from memory and start estimating from a record. Write your estimate down before you begin, capture how long the task really took, and compare the two. After several similar tasks you have a reference range for that kind of work. Your next estimate then comes from what actually happened last time, not from how the work felt, which is usually shorter than it really was.

What is the best way to compare estimated time with actual time?

Divide the actual time by the estimate for each task. A result of 1.0 means you were right, 1.5 means the task took half again as long as you thought, and 0.8 means you overestimated. Group the ratios by task type and look at the middle value rather than the average, because one disastrous task can distort an average and make every later estimate too long.

Do I need a time tracker to estimate tasks accurately?

No. A spreadsheet with four columns (task, type, estimate, actual) is enough, as long as you write the start and end times as you go. A tracker helps because people forget to log, and a forgotten entry is a missing data point. Timer apps need you to press start. Automatic trackers record in the background, so you fill in the task names afterward instead of the times.

Is there a free app that records how long tasks take on a Mac?

Yes, several. ActivityWatch is free and open source under MPL-2.0, records the active app and window title, and keeps data on your device. Dayflow is free under the MIT license, records the screen at one frame every 10 seconds, and has AI write a timeline. Toggl has a free plan for up to 3 users, but it relies mainly on timers you start yourself.

Which tool beats Dayflow for estimating billable client work?

Toggl or Timing. Dayflow has no invoicing, billable rates, team reports or payroll approvals. Toggl offers billable rates on paid plans, plus profitability reports and timesheet approvals on Premium, and its Jira and Asana integrations tie time to tasks. Timing is Mac-only and offers billing status tracking, report rounding and GrandTotal invoicing integration depending on the plan. If your estimates feed a quote or an invoice, either fits better.

How many past tasks do I need before my estimates improve?

There is no fixed number. A handful of comparable tasks is enough to see whether you run consistently over, consistently under, or all over the place. Each new data point narrows the range. The bigger problem is usually task types that are too broad, such as lumping a one-line fix together with a database migration, which makes the range useless no matter how many entries you collect.

Should I just pad every estimate by a fixed percentage?

Not blindly. A flat padding rule assumes you are wrong by the same amount on every kind of work, and your own history will usually show otherwise. You might be accurate on writing and far off on anything involving another team. Use a separate multiplier per task type, taken from your recorded actuals, and give a range rather than a single number when the history is spread out.

Can Dayflow tell me exactly how long a specific task took?

It gives you a timeline of what was on your screen, written up by AI, which you can read to find when a task started, when you left it and when you came back. It works from frames taken every 10 seconds, so treat it as a record to check, not a stopwatch. The AI summaries can miss or misinterpret work, so confirm the task boundaries yourself before you log an actual.

What can I use to track task time automatically on Windows?

Dayflow is Mac-only, so it is not an option. ActivityWatch runs on Windows, Mac, Linux and Android and is free. Rize runs on Mac and Windows with automatic app and website tracking, starting at $9.99 a month billed annually after a 7-day trial. Toggl has Windows, web and mobile apps, and the vendor also lists automated background tracking in its desktop app.