Recheck an open news item by revisiting five things: the primary source, the advisory records, your own evidence, the status of any fixes, and your closing criteria. Do it on a fixed day with a short checklist, note what changed, and either close the item or set the next recheck.
Why a recheck matters
First reports are rarely final. Write-ups get corrected. Advisory records are created, edited and sometimes withdrawn. The GitHub Advisory Database documents search options for recently updated and withdrawn records for exactly this reason: records move.
An item you closed on day one may no longer be correct on day seven. An item you left open and forgot may have been quietly resolved. A scheduled recheck keeps both from happening.
When to schedule it
Put the recheck time in the item the moment you open it. Good defaults:
| Item state | Suggested first recheck |
|---|---|
| Active incident, you are affected | Same day, several times, then daily |
| You are not affected but the story is evolving | Next business day |
| You are not affected, story is stable | One week |
| Waiting on a vendor or maintainer | The date they promised, or three business days |
Choose a clock time, not "later". Write who owns the recheck.
The five point recheck
1. Primary source. Reopen it. Compare it to your archived copy. Has the affected version list changed? Has the recommendation changed? If yes, note the differences with the date. The post on archiving a write-up explains why you want the old copy.
2. Advisory records. Search the advisory database for the package, sorted by recently updated. GitHub's documentation lists the sort:updated-desc and updated: qualifiers. Look for new records, edited ranges and withdrawals.
3. Your evidence. Does the evidence in the ticket still hold? If your answer was based on a lockfile, has the lockfile changed since? If you pinned a version, is the pin still in place?
4. Fixes and actions. If a fixed version or a clean release has appeared, plan the move to it. If you took a temporary step such as pausing an update, decide when to lift it.
5. Closing criteria. Are the conditions you wrote at the start now true? If so, close. If not, set the next recheck.
A worked example
On Monday you opened an item about a library with a reported flaw in versions 2.0 through 2.4. Your services use 2.5.1, so you recorded "not affected, recheck Monday next week" with a link and an archived copy.
On the next Monday you run the five points.
- The maintainer's notice now says 2.5.0 and 2.5.1 are also affected. The archived copy lists only up to 2.4. The difference is the finding.
- The advisory database record was updated on Thursday to extend the range.
- Your evidence, "we run 2.5.1", is now the evidence that you are affected.
- A fixed version 2.5.2 was released on Friday.
- The item cannot close. You reopen it as active, schedule the upgrade, and set a daily check until it ships.
Had you closed the item permanently on day one, you would have missed the change. The recheck turned a mistake from a silent one into a caught one.
Make closing a decision
Closing means something specific: your criteria are met and the evidence is attached. Write a short closing note: what the item was, your final verdict, the evidence, and the date. For items where you were not affected, include the reason, such as the version you run or the feature you do not use.
Do not close because the news cycle moved on. Attention fades long before risk does.
Keep the routine light
A weekly slot of fifteen minutes works for most teams. Put it in the calendar as a recurring event, with a short shared list of open items. Review the list, run the five points on each, update or close. If the list is long, that is itself a signal to look at which items are open and why.
For items that stay open for weeks, move them out of the news routine and into your normal work tracking. A waiting item is a task, not a news story.
What a good recheck note looks like
A recheck note should be short and dated. Here is a template that works.
Recheck 26 Oct, 10:00 UTC, owner: Dana
Primary source: changed (affected range extended to 2.5.x), archived copy updated
Advisory record: updated 23 Oct, range matches primary source
Our evidence: service B runs 2.5.1, now in range
Action: reopened as active, upgrade to 2.5.2 planned, daily check until shipped
Next recheck: 27 Oct, 10:00 UTC
Each line answers one of the five points. A reader who joins later can see the whole story in half a minute.
Mistakes in rechecks
| Mistake | Effect | Fix |
|---|---|---|
| Skipping the comparison with the archived copy | Silent changes go unseen | Always diff against your saved copy |
| Rechecking only the headline source | Records elsewhere may have moved | Check the advisory database too |
| Closing for lack of news | Risk may remain | Close on criteria, not on silence |
| No next date on a no change recheck | The item drifts | Always set the next time or close |
| One person holds every recheck | Items stall when they are away | Name a backup |
Treat the recheck as part of the item, not as an extra. The item is only finished when the closing criteria are met and written down.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a project is watched over time, since a dependency can change status after you last checked.
Safeguard's continuous monitoring is built on the same idea: new advisory data is checked against the inventory you already have, so some rechecking happens without a calendar reminder.
Quick check
How often should I recheck an item where I am not affected?
About a week later is a good default if the story is stable, or the next business day if it is still developing.
What if my recheck finds nothing changed?
Record "rechecked, no change" with the date and either close the item or set the next recheck. A dated no change note is useful evidence.
Who should own the recheck?
One named person, ideally whoever opened the item. A recheck owned by nobody tends not to happen.
Sources
Last reviewed: 19 October 2026.
