When your tasks are scattered across dozens of Obsidian notes, the fix is not to move them all into one giant list, it is to leave them where they live and pull them into a single view with a query. Obsidian’s strength is that a task can sit in the note it belongs to, the project, the meeting, the daily note, and a query gathers every one of them into one place on demand. So consolidating scattered tasks is a two-part job: a light cleanup so your tasks are consistently written, and one aggregating query that surfaces them together without you ever relocating a thing. This shows the minimal cleanup that does not require rebuilding your vault, and how to build the single view that ends the scatter.
The scattered feeling is real and worth diagnosing before you act, because the wrong fix makes it worse. If the problem is genuinely that tasks are spread out, a query solves it. If the deeper problem is too many notes or an over-built system, consolidating tasks into one mega-note just relocates the mess. Name which you have first.
Diagnose the real problem
Scattered tasks are usually one of three distinct problems wearing the same shirt, and each has a different fix. The first is pure dispersion: your tasks are fine, just spread across many notes, so you cannot see them together. The second is inconsistency: tasks are written so differently, some with dates, some bare, some tagged, some not, that no single query can catch them all. The third is overload: there are simply too many notes and too much going on, and the tasks are a symptom of a vault that has outgrown its structure.
| Symptom | The real problem | The fix |
|---|---|---|
| Tasks live in many notes, hard to see together | dispersion | one aggregating query |
| A query misses tasks written differently | inconsistency | a light standardisation pass |
| Everything feels like too much, not just tasks | overload | reduce scope, then aggregate |
Be honest about which one you have. A query fixes dispersion instantly; it cannot fix a vault that is overwhelming for deeper reasons. If it is overload, the broader approaches are in feeling overwhelmed with too many tasks; if it is dispersion or inconsistency, read on; and if the issue is really that short tasks and long projects are tangled together, handling short tasks vs long projects in Obsidian sorts that out.
The minimal cleanup, without rebuilding
You do not need to reorganise your vault to consolidate tasks; you need your tasks written consistently enough that one query can find them all. The lightest version of this is a single convention: decide how a task is marked, and apply it going forward without retrofitting everything at once. The simplest convention is just the Markdown checkbox, since the Tasks plugin already reads every - [ ] line in the vault. If you want to separate real tasks from incidental checklists, add a consistent tag like #task and use it as a global filter.
Crucially, this is forward-looking, not a big-bang migration. Standardise how you write tasks from today, and do a ten-minute pass on your handful of most active project notes to bring their tasks in line. Leave the rest; old tasks in dormant notes will surface when you touch those notes again. A minimal cleanup that you finish beats a total reorganisation you abandon halfway.
Here is the whole checklist, and it is deliberately short.
| Check | Why it matters |
|---|---|
| One way to mark a task (a checkbox) | so one query can find every task |
| A consistent tag if you separate task types | keeps checklists out of your task view |
| Dates only where they genuinely matter | a query can sort by them; do not over-date |
| Your active project notes brought in line | most of your live tasks live in a few notes |
| Dormant notes left alone | they surface when you next open them |
Nothing here asks you to move a task or restructure a folder. The point is consistency going forward, not a perfect past.
Build the single view
With tasks written consistently, one query ends the scatter. Create a note, your daily note is the natural home, and add a Tasks query that gathers open tasks from across the entire vault, filtered to what is due or actionable and grouped by the note they came from. Now every scattered task appears in one live list, while each task still physically lives in its own note, so you get a unified view without losing the context that made keeping them in the vault worthwhile.
This is the resolution of the apparent contradiction: consolidation and context are not opposites in Obsidian. The tasks stay distributed for context; the query centralises them for action. The full landscape of task tooling around this is mapped in Obsidian task management.
If you want the query to do more than the Tasks plugin’s own language allows, for example mixing tasks with other note metadata into a project dashboard, Dataview is the tool people reach for, and the long-running Obsidian forum thread on Dataview versus task plugins is a good map of the trade-offs. The one rule to carry over is to keep task completion inside the Tasks plugin, because completing a recurring task from a Dataview view breaks its recurrence. For pure consolidation, though, you do not need Dataview at all; a single Tasks query is enough and simpler to maintain.
A worked example
Picture a vault where tasks are scattered: a couple in today’s daily note, several in a client project note, one buried in a meeting note from last week, a few in an inbox note you forgot about. Nothing is wrong with any of them individually; the problem is you have never seen them side by side. You spend ten minutes making sure each is a plain checkbox, tag the genuine tasks in your two active project notes with a shared tag, and add one query to your daily note that shows every open, tagged task due on or before today, grouped by note. The next morning, the meeting-note task, the client tasks, and the daily-note tasks all appear together in one list, each still linked back to its home. The scatter is gone, and you moved nothing. That is the entire method, and it scales to a vault of any size, right up to the point where the unified list itself becomes long enough to need ranking.
When one view is not enough
There is a limit worth naming. Once your vault is large, the single aggregating view can itself return more tasks than you can act on, and you are back to staring at a long, if now unified, list. Consolidating solved the visibility problem; it did not solve the deciding problem. A query gathers and groups, but it does not rank which of the surfaced tasks matters most given everything around it. That is where a deciding layer helps: ZPXE reads the same tasks your query gathers and ranks today’s priorities on-device with a reason for each, so a big consolidated list becomes a short ordered one. The attention stakes are real, since re-scanning an undifferentiated list feeds the task switching that research puts as high as 40% of productive time, and the case for making the deciding step explicit is in why your task app should explain itself.
Key takeaways: ending scattered tasks in Obsidian
Do not move your scattered tasks into one giant list; leave them where they live and pull them together with a query. First diagnose whether you have dispersion, inconsistency, or genuine overload, because only the first two are solved by aggregation. Do a light, forward-looking cleanup, one consistent way of writing a task plus a ten-minute pass on your active notes, rather than rebuilding the vault. Then build one Tasks query in your daily note that gathers open tasks from everywhere, so you get a unified view while each task keeps its context. And when even that unified view grows too long, add a deciding layer to rank it, because visibility and deciding are different problems.
Quick answers
How do I gather scattered tasks in Obsidian?
Leave the tasks where they live and pull them together with a query rather than relocating them. Write your tasks consistently, at minimum as plain Markdown checkboxes, then use the Tasks plugin to add one query in your daily note that gathers open tasks from across the vault, grouped by their source note. Every scattered task now appears in one live list while still physically living in the note that gives it context. Consolidation and context are not opposites in Obsidian.
Do I need to reorganise my vault to fix scattered tasks?
No, and you should not try. Rebuilding the vault is a big-bang project people abandon halfway, and it is not what fixes scatter. What you need is consistency in how tasks are written, going forward, plus a ten-minute pass on your most active project notes to bring their tasks in line. Old tasks in dormant notes will surface when you next open those notes. A minimal cleanup you finish beats a total reorganisation you do not.
Why do my tasks feel scattered in Obsidian?
Usually one of three reasons. Dispersion: your tasks are fine but spread across many notes, so you never see them together, which a query fixes. Inconsistency: tasks are written so differently that no single query catches them all, which a light standardisation fixes. Or overload: there are simply too many notes and too much going on, and the scatter is a symptom of a vault that outgrew its structure, which needs reducing scope, not just aggregating. Diagnose which before acting.
Should I put all my tasks in one note?
No. Moving every task into one mega-note throws away Obsidian’s main advantage, that a task sits beside the material that gives it meaning, and it just relocates the mess into a single unwieldy file. The better pattern is to keep tasks distributed for context and use a query to centralise them for action. You get a single view without a single file, so nothing loses its home and nothing becomes an unreadable wall of checkboxes.
When is consolidating tasks not the real fix?
When your problem is deciding, not seeing. If you consolidate your tasks into one clean view and still freeze because the list is long, aggregation has done its job and exposed a different problem: you can see everything but cannot tell what matters most. A query gathers and groups; it does not rank. At that point the fix is a deciding layer that weighs the surfaced tasks and shows its reasons, turning the unified list into a short ordered one, rather than more consolidating.
