Close a task in Microsoft Planner and its history is gone. Not hidden, not archived — gone. There’s no burndown chart, no completion-trend line, no “how did this plan’s workload move over the last month” view, on any Planner tier. The Graph API gives you two real dates per task — when it was created, when it was marked complete — and nothing about what happened in between. That’s not a UI gap you can route around with a report; it’s a data gap. Here’s exactly what Planner and its API expose, why even Premium’s “Task History” doesn’t close it, and what’s actually reconstructible versus what genuinely isn’t.
Does Microsoft Planner have a burndown chart?
No, at any tier. The closest native thing is the Charts view’s Status breakdown — a bar count of not-started / in-progress / completed / late tasks, documented by Microsoft Support and covered in more depth in our cross-plan dashboard piece. That’s a real chart, but it’s a snapshot of right now. Reload it tomorrow and you get tomorrow’s snapshot — there’s no way to see Monday’s bar next to today’s, because Planner never stored Monday’s.
Burndown, velocity, “completion rate over the last four weeks” — these are all trend questions, and Planner has no trend surface. Nothing to toggle on, no Premium upsell that adds it. It simply isn’t there.
What does the Microsoft Graph API actually expose per task?
Two dates, and that’s the whole story. The plannerTask resource in Graph v1.0 has exactly these date/time-relevant fields, per the official schema:
| Field | What it is |
|---|---|
createdDateTime | Read-only. When the task was created. |
completedDateTime | Read-only. When percentComplete was set to 100. |
dueDateTime | Editable due date. |
startDateTime | Editable planned start date. |
percentComplete | Current value only — 0/50/100, no history of prior values. |
That’s it. No statusChangedDateTime, no startedDateTime for when a task actually moved to “in progress,” no changelog relationship, no history or activity endpoint anywhere in the Planner API surface. percentComplete tells you where a task stands today; it carries no memory of where it stood last week. If a task bounced from in-progress back to not-started and back again three times, Graph shows you none of that — only whatever its current value happens to be.
Doesn’t Planner Premium’s “Task History” already solve this?
It looks like it should, and it doesn’t — for two separate reasons. Microsoft did ship a real changes pane called Task History, announced on the Planner blog: it logs who changed a field, when, and the old/new value — assignments, buckets, labels, progress, dependencies. That’s a genuine audit log.
Two limits keep it from being an answer here:
- It’s Premium-only. Viewing it requires a Project Plan 3 (or greater) license — free/Basic Planner users don’t get it at all.
- It isn’t in the Graph Planner API, even if you pay for it. Premium plan data, task history included, lives in Dataverse rather than the classic Planner store. A Microsoft Q&A thread confirms it plainly: “Premium plans and tasks are not available on the standard Planner API in Microsoft Graph… The data for Planner Premium is stored in Dataverse. Therefore, the supported method to access and modify this data is by using the Dataverse Web API” (Microsoft Q&A).
/planner/plansand/planner/tasksin Graph simply don’t see it.
So Task History is real, but it’s invisible to every Graph-based reporting tool — including virtually all of them, since most Planner reporting integrations (this one included) are built against the standard Graph Planner API, not a Dataverse OData connection into someone’s Premium tenant. For the overwhelming majority of Planner users — anyone on Basic Planner, which is most of it — the feature doesn’t exist to begin with.
Why people keep asking for this
This isn’t a niche complaint. A Microsoft Community Hub thread titled almost exactly “Planner Task History” has been open since 2020 and was still drawing replies in 2026 — six years of the same question, “can I get task history via OData/Graph,” and the same answer from a Microsoft employee in the thread: “there isn’t a change log for tasks that you can access.” The workaround people land on — a Power Automate flow that posts task creation/completion events to a Teams channel as they happen — only captures history for tasks that existed after you built the flow. It can’t retroactively tell you anything about a task that changed status last month, because nothing was listening then.
What’s actually reconstructible — and what genuinely isn’t
This is the part worth being precise about, because it’s easy to overstate in both directions.
What you can build retroactively, today, for tasks that already exist: a created-vs-completed trend. createdDateTime and completedDateTime are both real, both stored per task, and both available the moment you query Graph — no advance setup required. Group completed tasks by their completedDateTime and you get a genuine “tasks completed per week” curve, even for a plan you’re looking at for the first time. That’s useful and it’s honest.
What you cannot build retroactively, no matter what tool you use:
- Time-in-status, at the task grain. Because Graph never records when a task moved between not-started, in-progress, and completed — only the current
percentComplete— there is no way to answer “how long did this task sit in progress” for any task, past or present. This isn’t a missing feature to route around; the data was never captured, by Planner or by Graph, so no amount of clever querying recovers it. - A point-in-time snapshot of open work. “How many tasks were open, by bucket / assignee / priority, on July 15th” requires having recorded that state on July 15th. Bucket assignment, priority, and who owns a task can all change after the fact, so you can’t infer July 15th’s picture from today’s data — today’s data reflects today. A real burndown curve — the shape everyone actually wants, work remaining over time, broken down by the fields that matter — needs an external system taking daily snapshots, and its history can only run forward from the day that system turned on. There’s no way to backdate it past that point, for anyone.
The honest way to get a burndown and trend view
Given both of those limits, the only way to get real burndown/trend reporting is to run a daily snapshot process yourself — pulling tasks from every plan on a schedule and storing counts by status, bucket, priority, and assignee each day, then charting the deltas. That’s a real engineering project: a scheduler, a store, retention, and enough runway before it’s useful to show anything but flat lines.
It’s exactly what Team Workload’s Trends view is built on. It runs a daily snapshot engine across every plan you can access and charts completion trend and burndown from those snapshots — no Power Automate flow to wire per plan, no Dataverse access, no Premium license requirement. And it’s held to the same honesty limit as anyone else’s data: the curve is real and gets more useful every day forward from when your plans started being tracked, not backfilled to before that, because — as this whole page has been about — nobody can backfill that. If you also want the day-to-day view underneath the trend, the cross-plan dashboard and the overdue report are the current-state pieces Trends sits on top of.