Dataview queries worth having in a developer vault

Sub Engel — Mon, 28 Sep 2026 00:43:59 +0000

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
---

Then:

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

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
```

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:
---

```dataview
TABLE decided, reviewed, choice(reviewed < date(today) - dur(1 year), "revisit", "ok") AS "Freshness"
FROM "decisions"
WHERE status = "accepted"
SORT reviewed ASC
```

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"))

"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
```

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
```

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
---

```dataview
TABLE repo, pr, status, opened
FROM "reviews"
WHERE status = "waiting" OR status = "changes-requested"
SORT opened ASC
```

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)

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
```

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
```

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
```

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).

DEV Community: Sub Engel