Data status
What this server has read from GitHub and the other sources, and how fresh it is. The same data is at /api/v1/sync.
GitHub
Pull requests
34222 stored · every open one read · updates read up to 5m ago
Issues
10807 stored · every open one read · updates read up to 5m ago
History since 2020
in progress: the numbers on the state of nixpkgs grow while it reads
Tokens
no GitHub App · the bot token · 3 lent by people who signed in
Updates
one every 10 minutes · the last took 10 minutes and ended 13m ago
Notifications
the notifications of the bot account, read every 60 seconds · the last read 0m ago · 187 threads in the last hour · 84 seconds on average from a change on GitHub to its read here · no errors in the last hour
Full walk
every update reads the pull requests and issues that changed since the last walk, one every 30 minutes · the notifications poller is healthy, so the walk is only the safety net
nixpkgs and package health
Index
89a0beb079b4 · 36844 packages, 2136 NixOS modules, 105 teams · built 14h agoChannel nixos-unstable
55bfb4d7437b · 36795 attributes · this revision first seen 21h agoChannel nixos-26.05
26f4107e47e3 · 35253 attributes · this revision first seen 21h agoUpstream versions
repology, read 22h ago · 18216 attributes behind upstream
Advisories
security tracker, read 22h ago · 1520 attributes with advisories
Packaging hygiene
from the nixpkgs index, with no network access · 20823 of 36844 packages have a gap in meta or no versionCheckHook
OSV
the exact version of each PyPI, crates.io and npm package, 1000 to a request, once a day · read 21h ago · 11492 packages asked · 96 with advisories, 503 matches
OSV records
the summary and severity of each match, 200 a run · read 8m ago · 0 records read, 0 failed · 0 left
Upstream tags and registries
git tags over HTTPS, crates.io, PyPI and npm; 300 requests a run, the packages people maintain or watch first; they overrule repology · read 7m ago · 300 remotes and registries asked · 307 packages: 75 behind, 182 current, 50 unclear, 0 unreachable · 4487 of 28341 still due
Severity
CVE Program records (CVSS and CISA exploitation), 300 a run · read 8m ago · 0 records read, 0 not published · 3683 of 3691 CVEs have a score · 0 left
NVD
CVSS for the CVEs without a score in their record, 50 a run, only with an API key · read 8m ago · 0 of 0 asked got a score · 0 left
EPSS
FIRST's chance of exploitation, every tracked CVE once a day · read 21h ago · 3520 of 3527 CVEs scored
Health task
its own task, one run every 10 minutes: a slow source does not delay the GitHub updates
Hydra builds
asked when a package or module page is shown, at most 4 at a time and 30 a minute, kept one hour · 1538 jobs kept · 0 page views not asked since the start
Flake rescans
off on this server: people upload reports from their own machines
Event log
Events
6380 stored · newest from 0m ago · the Events API is polled, and GH Archive fills the gaps each hour
Notification emails
off on this server: its operator did not set up SMTP
Archive of issues and pull requests
NixOS/nixpkgs
70597 issues and pull requests stored (224.1 MB) · oldest number reached #502925 · 12.3 % of the repository · about 7 days left at the current pace · 0 due · 300 per run, a run every 5 minutes · the last ended 0m ago · 3690 items fail; the server tries each again a day later
How fast changes show here
A bot account watches nixpkgs, and GitHub notifies it of each issue and pull request that changes. This server reads those notifications every 60 seconds, and reads each changed item again at once. A review, push or merge on GitHub shows here in about a minute (84 seconds on average in the last hour). The full walk runs every 30 minutes, for anything the notifications miss.
The Events API keeps only the last 300 events, so a busy hour loses some events of the event log until GH Archive brings them, about an hour later.
If the NixOS organisation forwarded the nixpkgs webhooks here (an organisation webhook, or a GitHub App installed on the repository):
- each change would show in seconds;
- no event would be lost in a burst;
- the updates would only check, so the rate limit would go to the older data and to the issue bodies.
Maintainer Mode has no webhook receiver yet: GitHub sends webhooks only to the administrators of a repository. See docs/events.md.