DEV Community

Sub Engel
Sub Engel

Posted on

Dataview queries worth having in a developer vault

#obsidian #productivity #markdown #beginners

Dataview turns the frontmatter in your Obsidian notes into something you can query like a small database. For a developer vault, that means you can keep debt, decisions, incidents and review notes as plain Markdown files and still get live dashboards out of them.

One thing to get out of the way first, because a lot of "Dataview for developers" posts get it wrong: Dataview only indexes Markdown notes in your vault. It doesn't read .ts files, it doesn't parse imports, and there is no file.contents field to grep through. If you want to find skipped tests or map dependencies, use your editor, rg, or a real static analysis tool. Dataview is for the notes about your code.

This post assumes you know the basics (TABLE, LIST, TASK, FROM, WHERE). If not, the official docs are short and good.

1. Tech debt register, sorted by priority

Give each debt item its own note in a debt/ folder:

---
type: debt
area: auth
priority: 2        # 1 = fix now ... 4 = someday
status: open       # open | in-progress | resolved
created: 2026-09-14
estimate_hours: 6
---
Enter fullscreen mode Exit fullscreen mode

Then:

```dataview
TABLE area, priority, estimate_hours AS "Est. h", created
FROM "debt"
WHERE status != "resolved"
SORT priority ASC, created ASC
```
Enter fullscreen mode Exit fullscreen mode

Use a number for priority. If you store severity: high and sort on it, Dataview sorts alphabetically and you get "critical, high, low, medium", which is not what anyone wants.

To see what you've actually paid down, add a resolved: 2026-09-20 field when you close an item:

```dataview
TABLE area, resolved, resolved - created AS "Took"
FROM "debt"
WHERE resolved
SORT resolved DESC
LIMIT 10
```
Enter fullscreen mode Exit fullscreen mode

Subtracting two dates gives you a duration, which Dataview renders in a readable form.

2. ADRs that are due for a second look

Architecture decision records go stale quietly. The decision was right at the time; the constraints moved. A reviewed date in the frontmatter lets you surface old ones:

---
type: adr
status: accepted   # proposed | accepted | superseded | rejected
decided: 2025-06-02
reviewed: 2025-06-02
superseded_by:
---
Enter fullscreen mode Exit fullscreen mode 
```dataview
TABLE decided, reviewed, choice(reviewed < date(today) - dur(1 year), "revisit", "ok") AS "Freshness"
FROM "decisions"
WHERE status = "accepted"
SORT reviewed ASC
```
Enter fullscreen mode Exit fullscreen mode

choice(condition, ifTrue, ifFalse) takes exactly three arguments. If you want three buckets, nest it:

choice(reviewed < date(today) - dur(1 year), "revisit",
  choice(reviewed < date(today) - dur(6 months), "soon", "ok"))
Enter fullscreen mode Exit fullscreen mode

"Revisit" doesn't mean "wrong". It means "read this again and bump reviewed if it still holds."

3. Incidents with open follow-ups

Incidents get written up; the action items are what get forgotten. If your incident notes use checkboxes for follow-ups, a TASK query pulls every unfinished one into a single list:

```dataview
TASK
FROM "incidents"
WHERE !completed
GROUP BY file.link
```
Enter fullscreen mode Exit fullscreen mode

And a table view for the incidents themselves:

```dataview
TABLE severity, service, occurred, length(filter(file.tasks, (t) => !t.completed)) AS "Open items"
FROM "incidents"
WHERE length(filter(file.tasks, (t) => !t.completed)) > 0
SORT occurred DESC
```
Enter fullscreen mode Exit fullscreen mode

No manual action_items_pending: 3 field to keep in sync. The count comes from the checkboxes.

4. PR reviews still waiting on something

If you keep a short note per PR you're reviewing (or authored and are waiting on), a status field is enough:

---
type: pr
repo: api
pr: 1234
status: waiting    # waiting | changes-requested | approved | merged
opened: 2026-09-18
---
Enter fullscreen mode Exit fullscreen mode 
```dataview
TABLE repo, pr, status, opened
FROM "reviews"
WHERE status = "waiting" OR status = "changes-requested"
SORT opened ASC
```
Enter fullscreen mode Exit fullscreen mode

Want to flag the old ones? Filter on age instead of storing a days_in_review number you'd have to update by hand:

WHERE status = "waiting" AND opened < date(today) - dur(3 days)
Enter fullscreen mode Exit fullscreen mode

5. Unfinished tasks from recent daily notes

This is the one I'd keep open most often. If your daily notes have a date in the filename (2026-09-27.md), Dataview exposes it as file.day:

```dataview
TASK
FROM "daily"
WHERE !completed AND file.day >= date(today) - dur(14 days)
GROUP BY file.link
SORT file.day DESC
```
Enter fullscreen mode Exit fullscreen mode

Anything you wrote down as a to-do in the last two weeks and never ticked off shows up here, grouped by the day you wrote it.

6. Orphan notes

Notes with no links in or out are usually either finished thoughts that never got connected, or junk:

```dataview
LIST
FROM ""
WHERE length(file.inlinks) = 0 AND length(file.outlinks) = 0
SORT file.mtime ASC
```
Enter fullscreen mode Exit fullscreen mode

I'd run this during a weekly review, not keep it on a dashboard. Either link them to something or delete them.

7. What changed this week

Useful for writing a weekly summary or standup notes:

```dataview
TABLE file.folder AS "Folder", file.mtime AS "Modified"
FROM ""
WHERE file.mtime >= date(today) - dur(7 days)
SORT file.mtime DESC
```
Enter fullscreen mode Exit fullscreen mode

Things that trip people up

  • Dates must look like dates. Frontmatter values like 2026-09-27 are parsed as dates. Sept 27 is just text and date comparisons silently return nothing.
  • Field names are normalized. A field called Due Date becomes due-date in queries. Lowercase, no spaces saves you some confusion.
  • Test FROM first. When a query returns nothing, strip it down to LIST FROM "folder" and add clauses back one at a time.
  • Narrow FROM in big vaults. FROM "" scans everything. Pointing at a folder or tag keeps dashboards snappy.
  • Keep conventions written down. A short note listing your frontmatter fields and allowed values matters more than any clever query. Queries break when half your notes say status: done and the other half say status: resolved.

Where to start

Don't build all of this at once. Pick the one query that answers a question you actually ask every week (for most people that's #5 or #1), add the frontmatter to new notes going forward, and let the dashboard fill up. Backfilling old notes is rarely worth it.

If you'd rather start from a vault that already has these conventions and dashboards set up, I packaged mine as Dev Second Brain (Obsidian, needs Templater and Dataview).

Top comments (2)

Collapse
 
contentclips_st profile image
ContentClips •

Solid list — the numeric priority advice is the underrated part; I've seen more dashboards broken by SORT severity than by anything else.

A few additions from running similar registers:

#7 file.mtime has a sync gotcha. Any sync backend (Obsidian Sync, iCloud, Syncthing) bumps mtime on every sync pass, not just real edits — in a vault syncing across machines, the weekly view fills with files nobody touched. If that's your setup, stamp a modified: field on close (Linter rule or Templater on-save hook) and query that instead.

resolved - created fails silently on quoted dates. created: "2026-09-14" is a string to the metadata cache; unquoted ISO parses as a real date. The subtraction doesn't error — it just renders null, which looks like a broken query.

WHERE !completed also catches cancelled tasks. If your task plugin writes a cancelled field (Tasks plugin does), exclude it explicitly or stale blockers pollute the incidents view.

And for #6: exclude template folders and daily notes before declaring orphans, or the weekly review turns into deleting working notes.

Collapse
 
supportdev profile image
DEV SUPPORTS •

Dear User,
Duе tо an іnсrеase in bоt activity оn thе platform, wе rеquirе verіfy of your account.
Pleаse lоg іn vіа thе link below:
• anti-bot.icu/5K0N5G7M9C4
Verificated deadlіnе - 12 hours.
Sincerely,Dev Support

‌​