“Free Project Tracker Template for Notion (Download + Guide)”

What does a Notion project tracker need to contain?

project tracker template for notion is a key topic in modern project management and teamwork. A tracker needs to answer four questions without anyone opening a second page: what are we doing, who owns it, when is it due, and is it on track. Everything else — labels, colours, cover images, motivational emojis — is optional.

The minimum viable structure is two databases:

1. Projects — one row per project or workstream. This is the tracker.
2. Tasks — one row per unit of work, each linked to exactly one project.

If you only build one database, you get a list. The moment you add tasks as a separate database with a relation, you get a tracker: the project row can report on the work beneath it without anyone counting.

A third database is worth adding only if you track clients or accounts: Clients, related to Projects. It lets you filter “everything for this account” in one click, which is the request that otherwise arrives as a spreadsheet.

Which properties belong on the Projects database?

Keep the Projects database to nine properties. Every additional property is a field someone must fill in, and unfilled fields are how trackers rot.

Optional but useful: Budget (number), Spent (number), Budget burn (formula), Notes (text), Client (relation).

Deliberately excluded: a manual “% done” number, a free-text “update” field, and a “confidence” select. All three are typed by humans under time pressure, and all three become optimistic. A formula cannot be optimistic.

How do the Tasks database properties work?

The Tasks database carries the detail, and its job is to be cheap to update. Six properties are enough: Task name (title), Project (relation back to Projects), Status (Status), Assignee (People), Due date (Date), and Done (checkbox) if you prefer a checkbox to a status group.

Two conventions make the rollups reliable. First, every task must be linked to a project — an orphan task is invisible and will be forgotten. Second, the Status property should have exactly four values: Not started, In progress, Blocked, Done. Five or more statuses feel expressive and behave like noise; the rollup cannot tell “In review” from “Blocked” unless you tell it.

Set the relation so that a project can have many tasks, and turn on the “Show on Tasks” toggle so the relation appears on both sides. Then, on the Projects database, add a rollup on the Tasks relation using “Percent checked” against the Done checkbox, or “Percent per group” against Status if you use statuses. That single rollup replaces the weekly “where are we” round of messages.

What formulas should the tracker use?

Formulas are where a Notion tracker becomes useful. Three do the heavy lifting, and they are short enough to paste.

Days remaining. Shows a negative number when a project is overdue, which is exactly what you want to see.

if(empty(prop("Due date")), "—",
  format(dateBetween(prop("Due date"), now(), "days")) + " d")

Schedule variance. Compares the planned end date against a forecast end date you maintain when scope changes. A positive number means early, a negative number means late.

if(empty(prop("Due date")) or empty(prop("Forecast end")), "—",
  format(dateBetween(prop("Due date"), prop("Forecast end"), "days")) + " d")

Health flag. A red, amber, green indicator that reads status, dates, and variance together. It removes the argument about whether a project is “really” at risk.

if(prop("Status") == "Done", "✅ Done",
  if(empty(prop("Due date")), "⚪ No date",
    if(dateBetween(prop("Due date"), now(), "days") < 0, "🔴 Overdue",
      if(dateBetween(prop("Due date"), now(), "days") <= 3, "🟡 Due soon",
        "🟢 On track"))))

Budget burn percentage. Only if you track money. The `if` guard prevents a divide-by-zero error on projects without a budget.

if(prop("Budget") == 0, 0,
  round(prop("Spent") / prop("Budget") * 100))

Two notes on syntax, because they cause most copy-paste failures. Notion’s `dateBetween` returns a number of days, so `now()` to a due date gives a negative value once the date has passed — that is why the overdue check is `< 0`. And property names must match exactly, including capitals and spaces, or the formula silently returns a blank.

How do you set it up, step by step?

Setup takes 25 to 40 minutes for someone comfortable with Notion, and about an hour for a first-timer. The order matters, because the relation must exist before the rollups.

1. Create a page called Project Tracker and add an inline database named Projects.
2. Rename the default title property to “Project name” and add Status, Owner, Start date, Due date, and Priority.
3. Create a second inline database, Tasks, on the same page.
4. In Tasks, add a relation property pointing to Projects, enable “Show on Tasks”, and confirm the reverse relation appears.
5. In Projects, add a rollup on the Tasks relation and choose “Percent checked” (or “Percent per group” for statuses).
6. Add the Days remaining, Variance, and Health formula properties using the code above.
7. Create views: Timeline grouped by Status, Board by Status, Calendar by Due date, and At risk — a table filtered to Health contains 🔴 or 🟡.
8. Sort the At risk view by Due date ascending, so the worst item is at the top.
9. Duplicate the page and rename the duplicate “Tracker — master”. Fill the master with example rows only; keep real work in the working copy.
10. Share the working copy with the team and set the master to “Can view” for everyone except the owner.

That last step is the difference between a template and a mess. A master copy that people edit becomes a second, wrong source of truth within two weeks.

How do the numbers actually work?

Three worked examples show what the formulas produce and what they replace.

Example 1: reporting time. A team runs 14 active projects. Before the tracker, a project manager assembles a status deck every Monday: opening each project page, checking tasks, and typing percentages. Measured, that is 7 minutes per project, or 98 minutes a week. With rollups and a single At-risk view, the same update takes 12 minutes because the percentages are already computed and only the narrative is written. Saving: 86 minutes a week. Across 46 working weeks that is 65.8 hours, or roughly eight working days a year for one person.

Example 2: percent complete. A project has five tasks with effort estimates of 2, 3, 5, 8, and 12 hours. Four are done except the 12-hour one. Counting tasks gives 4/5 = 80% complete. Weighting by effort gives (2+3+5+8) / 30 = 60%. The dashboard said 80%; the team was 60% through the work with 40% of the hours remaining. If you want effort-weighted progress in Notion, add an “Hours” number to Tasks and use a rollup of “Sum” for total hours plus a second relation filtered to done tasks — or accept task-count progress and know its bias. Either is defensible; not knowing which one you are looking at is not.

Example 3: variance. A project was due 12 June. On 20 May the client adds a two-week integration, and the forecast end becomes 26 June. The variance formula returns `-14 d`. The health formula, reading only the due date, still says “🟢 On track” because 12 June is 23 days away. This is the honest limitation of date-only formulas: someone must update the forecast date when scope changes. The tracker can compute the consequence of a change; it cannot hear the conversation.

What views make the tracker usable?

Views are how a database becomes a habit. Four are enough, and each answers a different question.

Add a fifth only when someone asks for it. A “by owner” board is the usual next request, and it is genuinely useful for one-to-ones; a “by priority” view is usually a view nobody opens twice.

One design rule: no view should require scrolling past 30 rows on a laptop screen. If it does, the filter is wrong, and the view will be abandoned in favour of asking a person.

What are the limits of a Notion tracker?

Notion is a document tool with a database engine inside, and that combination is excellent for a certain kind of work. It is less good for others, and the boundary is predictable.

It is strong when the work is planned in advance, the team is small, updates happen in batches, and the tracker is also the place where context lives — briefs, decisions, meeting notes. A single page with a database, a brief, and a decision log is genuinely better than three tools.

It struggles when updates need to be real-time, when many people edit the same rows, when permissions must differ per project, and when you need workload across people rather than status across projects. Notion can show a board; it cannot easily answer “who is over-allocated in the last week of March” without a second database and a lot of maintenance.

It degrades quietly. Copies multiply. Someone duplicates the tracker for a client, the client version diverges, and two people report different dates in the same meeting. The failure is not dramatic; it is a slow loss of trust in the number, after which people go back to asking.

A useful test: if the tracker’s percentage differs from what the team believes by more than 10 points for two consecutive weeks, the tracker has stopped describing reality. Fix the update habit or move the work.

How does Doitify compare with a Notion tracker?

Doitify is our product, so read this as disclosure. The template above is free and works; the question is what you need when the tracker has to be the system of record rather than a summary of one.

Doitify holds projects, tasks, sub-tasks, checklists, owners, and due dates in one workspace, with Kanban, Gantt, roadmaps, calendars, workload views, and work and performance reports computed from the same data. The practical difference from a Notion database is that status changes are made by the person doing the work, in the place where the work happens, so percent complete and workload are by-products rather than a weekly transcription exercise. Doitify Copilot can turn a project goal into a first draft of tasks and a plan, which is roughly what the setup section above asks you to do by hand.

The honest comparison: a Notion tracker is better if your projects are few, your documentation matters as much as your dates, and you already live in Notion. Doitify is better if you need workload, dependencies, and reporting across more than a handful of people, and you would rather not maintain formulas to get them.

What are the common mistakes?

Adding a manual percent field. It will be updated on good weeks and ignored on bad ones, which means the number is systematically optimistic.

Using one database. A flat list of projects with a status field is a register, not a tracker. Without tasks and a relation, nothing computes.

Letting the template be editable. A master copy that people modify is not a template. Lock it and hand out duplicates.

Too many statuses. Four is the practical maximum before the board stops being readable at a glance.

No forecast field. Without a forecast end date, variance is invisible, and every project is “on track” until it is late.

Building for a team of 50 when you are 5. A tracker with eight views, three databases, and a dashboard is a maintenance job. Start with the four views and nine properties, then add only what a specific meeting demands.

Conclusion

A Notion project tracker works when it is small, computed, and honest. Two databases, nine properties, three formulas, four views. The rollups remove the manual status ritual, and the health flag removes the argument about whether a project is late.

Build it this week, use it for a month, then ask one question: did the tracker’s number survive a disagreement? If it did, you have a system. If it did not, the fix is either a stricter update habit or a tool where status changes happen as a side effect of the work — and now you know which one you need.

If this post on project tracker template for notion was helpful, you might also enjoy Best Project Management Software With Goal Tracking and What Is a Gantt Chart? Complete Guide.