GitHub’s “updated” sort is based on the PR’s updated_at timestamp, which can change even when you don’t see an obvious new commit or comment. Background events like branch protection/ruleset changes, CI/checks being re-run or re-synced, metadata/index refreshes, or other internal maintenance can bump updated_at for many PRs at once, making them look “recently updated” without visible activity in the PR timeline. Unfortunately there’s nothing you can do on the repo side to fully prevent this because it’s driven by GitHub’s backend, but you can reduce confusion by filtering for true activity (e.g., review/comment activity, “updated by” signals in the timeline) or by tracking activity via the API/webhooks (issue_comment, pull_request_review, pull_request synchronize events) rather than relying solely on sort:updated-desc.

Hey,
Interesting issue! When a bunch of PRs all get marked as "updated" at the same time without any visible changes, it's usually caused by one of these scenarios:
Most likely culprit: Base branch changes
When commits are pushed to the base branch (usually main or master), GitHub updates the "last updated" timestamp on all open PRs targeting that branch, even though the PRs themselves weren't modified. Looking at the commit you linked (8dec720), if that was merged into your default branch around Jan 23 at 11:50 PM CET, that would explain why all the PRs got touched.
This is actually working as intended from GitHub's perspective - the PRs technically are affected because their merge base changed.
Other possible causes:

Branch protection rule changes - If someone modified branch protection settings, it can trigger updates across PRs
Required status checks added/removed - Changes to CI requirements
Label automation or bots - If you're running any GitHub Actions or bots that scan PRs periodically

How to prevent this (sort of):
Unfortunately, you can't really prevent this behavior since it's how GitHub tracks PR freshness when the base branch changes. However, you can work around it:

Filter by "recently updated by author" - Use search filters like:

is:pr is:open sort:updated-desc -author:app/github-actions

Use review status as a proxy - Sort by PRs that have recent comments or reviews instead:

is:pr is:open sort:comments-desc

Set up a bot - You could create a GitHub Action that adds labels like "recently-modified" based on actual PR changes rather than base branch updates.

To confirm this is what happened:
Check if commit 8dec720 was merged to your default branch around that timestamp. You can verify with:
bashgit log --all --oneline --graph --date=local --since="2026-01-23 22:00" --until="2026-01-24 01:00"

Hope this clears things up! It's definitely annoying for triage, but at least it's not a bug.