Site monitoring
An audit tells you what is wrong today. Monitoring tells you what changed, which is the question you actually have, because a site that was fine last month and is not fine now has a cause, and a site that has been failing the same check since 2023 is not news.
Docket re-audits on a schedule you set (daily, weekly or monthly) on your own machine, with no account, and the results stay there. Every re-audit is compared against the last one, and the comparison leads with what got worse.
It runs while Docket is open, and stops when you quit. The scheduler is a thread inside the app, not a background service and not a server. There is nothing left running on your Mac after you close it, and nothing running anywhere else at any time. A site that falls due while Docket is shut is picked up the next time you open it, so you get the check late rather than not at all. If you need an audit to run at 3am whether or not anybody is logged in, that is a job for the Linux CLI in cron or CI, and it is built for exactly that.
Every check keeps its report
A snapshot is enough to say what changed and to draw the trend, and it is not enough to read: it records which checks fired and how badly, not the detail, the fix or the URLs. So each scheduled check now keeps the full report it produced, and the site’s page offers it. Open it, or download it as PDF, HTML or JSON.
It has to be kept at the moment it is made. A report is rendered from an audit that is still in memory, and once the check has finished there is nothing left to render from, so a check that ran before this existed has no report to recover. The buttons show only the formats that particular check actually produced, rather than offering three and failing on two.
Regressions first, not alphabetically
The ordering is the feature. Most tools hand you the current state and leave you to notice what moved; you open the report, see forty issues, and cannot tell which three are new. Docket separates them: appeared, fixed, got worse, got better, and the score move per area.
A check that has been failing for six months is a decision you have already made, whether you made it deliberately or not. A check that passed last week and fails today is somebody's deploy. Only one of those needs you this morning.
What it will not tell you, on purpose
Two refusals, both cases of declining to produce a number that would look useful and be wrong.
It will not diff two audits that crawled very different numbers of pages. It says so instead. If last week reached 50 pages and this week reached 500 (because a sitemap appeared, or a crawl budget changed, or a section stopped being blocked) then comparing them invents dozens of "new" issues that were there all along and simply had not been reached. Every one of those alerts would be false, and you would spend the morning proving it.
Areas where only one side was evaluated are excluded from the competitor table, rather than shown as a win or a loss. If Docket could read your local SEO signals and could not read a rival's, the honest cell is empty. A tool that filled it would be handing you a lead you do not have.
Competitors, and the finding worth acting on
Attach rival sites and they are audited on the same settings, so the comparison is like-for-like rather than your thorough crawl against their shallow one. The table shows where you lead and trail area by area.
The most useful row is not the score. It is the list of issues every competitor has already fixed. That is the clearest evidence you get that something is both achievable in your market and expected in it: an issue nobody else has is a standard, not an opinion.
Where the history lives
In ~/.docket/, as plain JSON: a watchlist plus one compact snapshot per
audit, a few kilobytes each. Alongside them sits the full report from each site’s most
recent check. That one is not a few kilobytes, and it is replaced rather than
accumulated, so the folder grows with the number of sites you watch and not with the number
of checks you run. You can read any of it, back it up, put it in version control, or delete
it. Set DOCKET_HOME to keep it somewhere else.
There is no server of ours in this. The history is never uploaded, there is no account, and if you stop using Docket your history is still sitting in a folder you own, which is the difference between monitoring you rent and monitoring you have.
Scheduled audits are a promise to somebody else's server
A monitor is a program that visits a site repeatedly without a person present, so the politeness settings matter more than they do for a one-off audit. Docket crawls with the same concurrency and delay you set for a manual run, deduplicates URLs, and respects the page cap. If you are monitoring a site you do not own (a competitor) those settings are the difference between research and a nuisance.
Further reading
- When a report says nothing at all
- A finding's count is not decoration
- When two findings count the same pages twice
- When an audit blames the site for one template
- A caveat is not a gate
Common questions
How often does Docket re-audit a monitored site?
Daily, weekly or monthly: you choose per site. The re-audit runs on your own machine with the same crawl settings as a manual run, so a monitored site is not crawled harder than one you audit by hand.
Does monitoring keep running when Docket is closed?
No. The scheduler is a thread inside the app, so it stops when you quit and nothing is left running on your machine. A site that falls due while Docket is shut is re-audited the next time you open it. For unattended runs on a schedule, use the Linux CLI in cron or CI.
Does site monitoring need an account or a server?
No. The re-audits run on your Mac and history is stored in ~/.docket/ as plain JSON: a watchlist plus one small snapshot per audit. The history is never uploaded, and it stays yours if you stop using Docket.
Why does Docket refuse to compare some audits?
Because comparing a 50-page crawl with a 500-page crawl invents dozens of new issues that were always there and simply had not been reached. Every one of those alerts would be false, so Docket says the crawls are not comparable instead of producing the diff.
What does the competitor comparison actually show?
Where you lead and trail area by area, on rivals audited with the same settings, plus the issues every competitor has already fixed. Areas where only one side could be evaluated are left out rather than counted as a win or a loss.