diff --git a/assets/cron-scheduler-table.png b/assets/cron-scheduler-table.png
new file mode 100644
index 0000000..fd8386c
Binary files /dev/null and b/assets/cron-scheduler-table.png differ
diff --git a/docs/cron-scheduler.md b/docs/cron-scheduler.md
index 384b4af..b86e7a1 100644
--- a/docs/cron-scheduler.md
+++ b/docs/cron-scheduler.md
@@ -18,6 +18,10 @@ Jobs with no fixed time get their own list instead of a misleading grid cell:
 
 ![The heatmap's "no fixed time" section expanded — 15 real jobs excluded from the grid, including the manually-triggered-only Kestra flows and the PBS prune job with its mismatched datastore name](../assets/cron-scheduler-no-fixed-time.png)
 
+Both of those are Dashy's *rendered* view. This is the raw NocoDB table underneath it — the actual data structure, not the heatmap built from it:
+
+![The real "Cron Scheduler" NocoDB table in grid view, showing all 50 records with their Job Name, Category, Schedule Expr, Est Start, Duration, Resource Tags, and Source columns](../assets/cron-scheduler-table.png)
+
 ## Why a manual inventory instead of an auto-discovered one
 
 The harder, more "correct" version of this tool would auto-discover every scheduled job by querying Kestra's API, parsing every host's crontab and systemd timers, and re-syncing continuously. That was scoped down deliberately: auto-discovery across three genuinely different scheduling mechanisms (Kestra's API, systemd's timer units, cron's own format) is real engineering effort for a tool whose entire job is picking a good time slot for the next new job — a task that happens occasionally, not continuously. A manually-maintained table, kept honest by being checked at the one moment it actually matters (adding a new job), was judged the better return on effort than building and maintaining three different scanners for a problem that doesn't need real-time accuracy.