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 nothing uploaded. 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.
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. You can read it, back it up, put it in version control, or
delete it. Set DOCKET_HOME to keep it somewhere else.
There is no server in this. Nothing is 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.
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. Everything runs locally and history is stored in ~/.docket/ as plain JSON — a watchlist plus one small snapshot per audit. Nothing is uploaded, and the history 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.