The evidence establishes a real period where the dependency graph and alert state disagreed:

• At 13:33:33 UTC, the SBOM had Pillow 13.0.0 and no 12.3.0, while 41 alerts remained open.
• The refresh completed at 13:31:55 UTC.
• The records became fixed between 14:08:27 and 14:08:37 UTC, about 36 minutes later.

That proves eventual reconciliation, but not that the refresh caused it.

GitHub documents when Dependabot alerts are generated and how the dependency graph is populated, but does not publish a processing window or SLA for closing alerts after a dependency submission. Asynchronous reconciliation is consistent with this result; there is no documented basis for treating 36 minutes as either guaranteed or abnormal.

There is also no supported UI, REST, or GraphQL field meaning reconciliation pending. Owners can observe only input/output state:

• Default-branch commit, manifest content/path, and blob SHA
• Dependency graph or SBOM package version
• Alert ID/state/package/manifest and timestamps
• Dismissal fields
• Submission or refresh workflow status

Those distinguish graph still stale from graph current but alert evaluation not caught up, but cannot expose the internal queue or root cause. A successful refresh confirms submission completion, not alert reconciliation completion.

If it recurs, preserve the repository/default branch, commit and manifest blob SHAs, UTC timestamps, SBOM output, raw REST/GraphQL alert responses, GHSA IDs and ranges, workflow URLs/run IDs, and evidence that no dismissal/source change/additional refresh occurred. Avoid repeated refreshes while collecting evidence. If the graph is current and alerts remain inconsistent after one successful refresh, attach that bundle to GitHub Support; only GitHub can inspect the reconciliation job.

References: Dependabot alerts, dependency graph, graph troubleshooting, and alerts REST API.

The observed behavior and timeline (~35–40 minutes between manifest update and alert closure) reflect normal, expected asynchronous processing in GitHub’s security pipelines.

Direct Answers to Your Questions

1. Is this delay expected, and is there a documented processing window?

• Yes, it is expected. The Dependency Graph (which updates the SBOM immediately via HTTP 204) and the Dependabot Alert Engine operate on decoupled, asynchronous pipelines.
• Once the manifest changes, Dependabot queues an alert evaluation job to re-match your dependency graph against the GitHub Advisory Database. There is no strict SLA, but reconciliation typically completes within 15 to 60 minutes, occasionally longer during peak platform load.

2. Can maintainers distinguish normal pending reconciliation from a stale state via UI/API?

• Not directly. The public REST/GraphQL APIs and UI expose state outcomes (OPEN, FIXED, DISMISSED), not the internal event queue position or evaluation lag of the alert engine.
• If the manifest and Dependency Graph/SBOM already reflect the new version (e.g., Pillow 13.0.0), the system has ingested the data; any lingering open alerts simply indicate that the back-end evaluation worker has not processed the diff yet.

3. What is the recommended practice if this recurs?

• Avoid rapid manual refreshes: Spamming manual updates or dismissing alerts can fragment audit logs and reset worker queue backoffs.
• Wait 1–2 hours: Allow the asynchronous pipeline to reconcile naturally.
• Action threshold: If alerts remain OPEN after 24 hours despite the Dependency Graph and SBOM showing the patched version, file a ticket via [GitHub Support](https://support.github.com/) with the exact manifest commit SHA, SBOM diff, and affected alert IDs.