Early warning for your CRAN packages

CRAN watch is a small repository that keeps an eye on the R packages you maintain, contribute to or depend on. It runs on GitHub Actions, writes a dashboard to GitHub Pages and opens an issue only when something needs you.

Open the dashboard Make your own

Schedule #

Each job runs on GitHub Actions and commits what it found; the dashboard shows the result straight away. Times are Hobart (AEDT; an hour earlier in AEST).

Job	When	What it updates
`queue`	twice a day, 08:23 and 12:23	CRAN incoming queue; current CRAN versions and publish dates (the Published column); whether each CRAN version has a tag in the package's GitHub repo
`release`	after every `queue` run, and whenever you open or comment on a release issue or change config	the release board and each release issue's status comment
`watch`	every 6 days, about 06:17	CRAN check results, deadlines, archival, reverse dependencies, r-universe; issues and the weekly summary
`details`	weekly, Monday about 09:41	urlchecker and checktor on each CRAN release (the details pages)
`pkgcheck`	by hand only	rOpenSci pkgcheck for the packages listed in config

Any job can also be run by hand: Actions, pick the job, Run workflow.

What it watches

Each watcher reads a public source, compares it with what it saw last time, and records what changed. On every page a package's name links to its repository (or its CRAN page when it has none), its version to CRAN, and each status cell to the source it came from.

CRAN checks

The worst result across all CRAN flavors for every package, linked to CRAN's results page.

Deadlines and archival

A "fix before" date set by CRAN, or a package removed from CRAN. These open an issue straight away.

CRAN incoming queue

Where your submissions sit (newbies, pretest, pending, a reviewer's folder), including brand-new packages that are not on CRAN yet.

Reverse dependencies

Packages that depend on yours and are failing on CRAN, which is often the first sign a release broke someone.

GitHub tags

Whether the CRAN version has a matching tag (v1.2.3, 1.2.3 and similar) in the package's repository, linked to its GitHub release when there is one. "No tag" links to the repo's tags; the "No GitHub tag" tile lists them all.

r-universe

Whether each package is present in your r-universe and whether the CRAN metadata points back to your repository.

Package details

A weekly per-package page with URL checks (urlchecker), CRAN policy checks (checktor) and, on request, rOpenSci pkgcheck.

Releases

A board for packages on their way to CRAN: GitHub CI, checktor and urlchecker on the GitHub source, win-builder and mac-builder results, then the incoming queue until CRAN publishes. The same page lists every submission of yours in CRAN incoming.

How it works

Every job is the same loop, run on a schedule and committed back to the repository.

Fetch sources→ Diff against saved state→ Act on what changed→ Publish the dashboard

State lives in state/state.json, so each run knows what it saw last time and git history doubles as an audit log. CRAN flavors flake, so a problem must persist across runs before it counts, and an issue can be snoozed with a label until the problem changes character. Most changes go into one summary issue every few days that links here; only deadlines and archival get an issue of their own.

What you can use it for

Hear before CRAN emails

A new NOTE or ERROR shows on the dashboard days before the "please correct" message arrives.

Follow a submission

See which folder each submission is in, without remembering to check.

Coordinate several releases

One board shows which packages are ready to submit, which are waiting on win-builder or mac-builder, and which are in the queue.

Watch your ecosystem

Track packages you contribute to (found automatically from author lists) or depend on, without opening issues for them.

Triage in one place

Filter by severity, open issues or queue, and sort by status, date or alerts.

Make your own #

Everything specific to one person lives in config.yml. Fork, edit that file, and turn on Pages.

Fork the repository Use the Fork button on GitHub. Then clear the previous owner's data so your first run starts fresh: delete state/state.json, docs/status.json, docs/queue.json, docs/published.json, docs/tags.json and the files in docs/pkg/.
Edit config.yml Set your Maintainer emails and the name forms that appear in author lists, and replace the previous owner's lists (watch, universes, repo_map, extra_packages, pkgcheck) with your own or empty ones.
```
maintainer_emails:
  - you@example.org
author_names:
  - Your Name
universes: [your-universe]
watch:
  - package: somepkg
    role: interest
repo_map: {}
```
Enable Actions and Pages In the Actions tab, enable workflows (forks start with them off). In Settings > Pages, deploy from the main branch, /docs folder.
Do a first run Actions > watch > Run workflow with "Dry run" ticked. It records state without opening issues. Then run queue and details once, and the dashboard fills in.
Tune it Change the schedules in .github/workflows/, choose which problems open issues with issue_kinds, or add a check to the details page by adding an entry to sections in scripts/details.R.

Reporting uses only the repository's own token and never writes outside it. The optional release tagging needs a separate WATCH_PAT secret and an explicit repo_map; leave both out and it never runs. The README has the full details.

Built on

CRAN's package database and check results through tools::CRAN_package_db() and friends, the r-universe API, the CRAN incoming folder (the same listing cransays and cransubs read), urlchecker, checktor, rOpenSci's pkgcheck, and the canary issues of hypertidy/gdal-r-ci.