obsidian dataview query for daily notes

5 Essential Obsidian Dataview Queries for Your Daily Notes Template

Stop treating your Daily Note like a diary.

Most people use Obsidian’s Daily Note as a text file. They dump a few bullet points, maybe a meeting log, and then close it, never to be seen again. It’s a “write-only” memory hole.

But if you look at the top 1% of power users, they don’t see a text file. They see a dashboard.

We are drowning in tools. According to the 2023 Microsoft Work Trend Index, 68% of employees suffer from “Digital Debt” and lack uninterrupted focus time. Recent data suggests many of us are juggling multiple apps just to manage knowledge. It’s exhausting. The switching costs alone are killing your flow state—a phenomenon confirmed by the Asana Anatomy of Work study, which found workers switch between apps up to 9 times a day. The solution isn’t another app; it’s making your existing one smarter.

By using the Dataview plugin, you can transform that static daily markdown file into a dynamic mission control center that aggregates your past, present, and future automatically. But there is a catch.

Most “copy-paste” tutorials online are broken. They offer code that fails when you sync devices, lags when your vault grows, or ruins your historical logs. We aren’t doing that here. We are going to build an Enterprise-Grade Daily Note Template using resilient, self-aware queries that actually work in the real world.

⚠️ IMPLEMENTATION PROTOCOL (READ FIRST):

  • The “Wrapper” Rule: The code blocks below are written in DQL (Dataview Query Language). You MUST wrap them in triple backticks like this to work:
    ```dataview
    PASTE THE CODE HERE
    ```
  • Folder Dependency: The queries explicitly look for folders named "Journal", "Inbox", or "Fleeting". If your folders are named differently (e.g., “Daily Notes”), the queries will return zero results. You must rename your folders or update the FROM "..." line in the code.
  • Indexing Lag: Upon first installation, Dataview may take 1-2 minutes to index a large vault. If the queries show “Dataview: parsing…”, simply wait.
See also  How to Add a Progress Bar to Obsidian Tasks Using CSS and Dataview

1. The “On This Day” Archive (Longitudinal Context)

User Intent: Rediscovery & Pattern Recognition

The Answer Target: Use this query to resurface notes from previous years on the same date. It fights recency bias by connecting your current problems to historical solutions.

You know that feeling when you smell old rain on hot asphalt? It instantly triggers a memory. That’s what we want for your notes. We want to engineer serendipity.

A naive approach is to ask Dataview for notes where file.day = this.file.day. This fails immediately because it matches the year too. You won’t see what you did on this day in 2022; you’ll only see what you did today. To fix this, we have to perform surgery on the date object, matching only the month and day integers.

The Resilient Query

LIST
FROM "Journal"
WHERE file.day.month = this.file.day.month
AND file.day.day = this.file.day.day
AND file.day.year != this.file.day.year
SORT file.day.year DESC

Why this beats the competition:

  • Leap Year Safe: By comparing .month and .day separately, this survives the February 29th edge case where “Day of Year” calculations often drift.
  • Recursion Proof: The line != this.file.day.year ensures your current note doesn’t clutter the list.
  • Speed Optimized: Notice the FROM "Journal". Never leave this blank. Scanning your entire vault for dates is a performance killer (more on this later).

obsidian dataview query for daily notes

2. The “Action Hub” (Context-Aware Task Radar)

User Intent: Execution & Prioritization

Here is a specific pain point most tutorials ignore: The “Ghost of Christmas Past.”

Imagine you have a query showing “Overdue Tasks.” You put it in your template. It works great today. But three years from now, when you look back at today’s daily note, that query will run again. It will show you the overdue tasks from the future (relative to that note). You ruin the historical snapshot of your day with the anxiety of your current backlog.

We need a Context-Aware query. It needs to ask: “Am I being viewed on the actual current day?” If yes, show overdue tasks. If no (I am a past note), show only what was scheduled for that day.

See also  Automate Your Meeting Notes: Best Obsidian Templater Scripts Copy-Paste

The “Ghost-Proof” Logic

TASK
WHERE !completed
AND (
  (due = this.file.day) OR
  (scheduled = this.file.day) OR
  (date(today) = this.file.day AND due < this.file.day)
)
GROUP BY file.link
SORT priority DESC, due ASC

This is the secret weapon. The clause date(today) = this.file.day acts as a gatekeeper. It ensures that the stressful list of overdue items only appears when you can actually do something about them. When you review this note next year, it will look clean, showing only what you planned for that specific Tuesday.

3. The “Input Log” (Velocity & Sync Safety)

User Intent: Tracking Creation Volume

What did you actually produce today? Not just tasks checked off, but ideas captured?

Most people use file.cday (Creation Date) for this. Do not do this. It is a trap.

If you buy a new MacBook and sync your vault via iCloud or Dropbox, the operating system often resets the “File Creation Date” to the moment the file was downloaded to the new disk. Suddenly, your entire history of notes looks like they were created on “January 22, 2026.” Your history is wiped.

The fix is to use a “Waterfall” method. We prioritize an explicit YAML created property (which is text inside the file and never changes), and only fall back to the system date if that property is missing.

The Sync-Proof Query

LIST
WHERE (created = this.file.day)
OR (file.cday = this.file.day AND !created)
AND file.path != this.file.path
SORT file.name ASC

Pro Tip: Configure your core “Templates” plugin to automatically insert created: {{date}} into the frontmatter of every new note. This future-proofs your vault against file system corruption.

4. The “Gardening Log” (Modification Tracker)

User Intent: Maintenance & Refinement

Knowledge work isn’t just about creating new files; it’s about refining old ones. This is the concept of “Digital Gardening.” You need to see which weeds you pulled and which plants you watered.

This query separates “New Ideas” from “Refined Thoughts.” It specifically looks for files modified today that were not created today.

The Refinement Query

TABLE file.mtime AS "Last Polished"
FROM -("Templates" OR "System")
WHERE file.mday = this.file.day
AND file.cday != this.file.day
SORT file.mtime DESC

The exclusion file.cday != this.file.day is critical here. Without it, your “Modified” list is cluttered with the same files found in your “Created” list (since a new file is technically also modified). This view gives you a clear visual of your review chain. It feels satisfying, like looking at a clean workbench after a long day of repairs.

See also  Automate Your Meeting Notes: Best Obsidian Templater Scripts Copy-Paste

obsidian dataview query for daily notes

5. The “Inbox Zero” Processor (Fleeting Notes)

User Intent: Workflow Hygiene

We all have “Fleeting Notes” those quick scribbles, phone numbers, or half-baked ideas that get lost in the folder structure. They are the digital equivalent of sticky notes falling behind your desk.

This query acts as a safety net. It defines an “unprocessed” note not just by its folder, but by its lack of connection. If a note isn’t linked to anything and isn’t tagged, it is dead weight. This query forces you to integrate it or delete it.

The Orphan Query

LIST
FROM "Inbox" OR "Fleeting"
WHERE length(file.outlinks) = 0
AND length(file.tags) = 0
AND file.cday <= this.file.day

This creates a relentless “Inbox Zero” loop directly on your daily dashboard. You can’t ignore the clutter when it’s staring you in the face every morning.

Performance Engineering: The “Anti-Lag” Guide

We need to talk about speed. I’ve seen vaults with 20,000+ notes grind to a halt because of bad Dataview code. When you open your Daily Note, you want it to snap open instantly, not spin like a jet engine while it scans every markdown file you’ve ever written.

Here is the golden rule of Dataview performance: Filter by Source (FROM), not by Attribute (WHERE).

Query Structure Search Scope Performance Impact
WHERE file.folder = "Projects" Scans Every File (Slow) F (Fail)
FROM "Projects" Scans Index Only (Instant) A (Pass)
WHERE contains(file.text, "x") Reads File Contents (Very Slow) F- (Critical)

Always use the FROM command to narrow down the search field immediately. If you are looking for journal entries, use FROM "Journal". If you are looking for tasks, try to tag them or keep them in specific folders if possible. The difference between scanning 500 files in a folder versus 20,000 files in a vault is the difference between a tool that works and a tool that fights you.

Final Thoughts

Implementing these queries isn’t just about “productivity.” It’s about trust. You need to trust that your system will surface the right information at the right time without you having to go digging for it.

Start by adding the Action Hub and the Input Log to your template today. See how it changes your relationship with your past self. Suddenly, you aren’t just writing into the void; you’re building a conversation with your own history.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top