GitHub · Pull requests · REST API · Checked October 26, 2026

GitHub: why pull requests update late outside github.com

GitHub tells other software about a change in one of two ways: it delivers a webhook to a web server someone set up, or it waits to be asked. A tool on your computer has no address GitHub can deliver to, so it asks again and again; what it shows is as old as its last read. GitHub's best practices for the REST API say to subscribe to webhook events instead of polling, and when you must poll, to poll on a fixed schedule only as often as you need, with conditional requests (checked October 26, 2026).

GET /repos/OWNER/REPO/pulls?state=open
If-None-Match: "644b5b0155e6404a9cc4bd9d8b1ae730"

HTTP/2 304

Why it is late

Asked, not told: between two reads nothing arrives. A change made right after a read shows at the next one.
304 Not Modified: a read that sends the etag of the last answer (If-None-Match) gets 304 while that answer has not changed. It says the data is the same, not that it is old, and with a token it does not count against the hourly limit (see "API rate limit exceeded").
Notifications: GET /notifications answers with X-Poll-Interval, how many seconds to wait before asking again (60 in GitHub's example). GitHub says it may grow when its servers are busy, and asks clients to obey it. Asked with If-Modified-Since and nothing new, it answers 304.
Lists made by search: review-requested:, user-review-requested:, reviewed-by: and author: are qualifiers of GitHub's search (GET /search/issues), which answers from its search index. GitHub's status page has reported incidents when that index fell behind: on December 23, 2025, results of issue and pull request searches were up to three minutes old, and on February 23, 2026, updates to issues and pull requests were not reflected in search right away.
Search has its own limit: 30 requests a minute with a token, 10 without. A tool that runs several searches at each read reaches it sooner than the hourly limit.

What to do

Read again: refresh the tool, or open the pull request on github.com.
A pull request a search does not show yet: the repository's own list (GET /repos/OWNER/REPO/pulls) is not a search; look there, and at GitHub's status page for an incident with Issues or Pull Requests.
Notifications from your own script: send the Last-Modified of the last answer as If-Modified-Since, and wait at least X-Poll-Interval seconds between reads.
As it happens: a webhook on the repository or organization, delivered to a server of yours.

GitHub pull requests in IntelliJ IDEA

Pull Request Inbox for GitHub, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, reloads its list every five minutes while its tool window is on screen ("Reload the list every 5 minutes while it is open, and tell me about new review requests" in Settings | Tools | Pull Request Inbox for GitHub, on by default), and at once with Refresh. While the tool window is hidden, nothing is read and nothing is announced. Each read sends the etag of the last answer, so an unchanged list comes back as 304. After a timer reload it shows a notification for each pull request that newly waits for your review; comments, approvals and checks are not announced. All open in the open repositories is each repository's own list; the other filters and scopes are GitHub's search, so they follow its index. The pull request you have open is read again in place at each reload, with its checks, reviews and comments, keeping the selected file and, while nothing in them has changed, where you were reading. The review inbox, diffs and conversations are free; approving, commenting and merging are Pro (US$1.50 a month, with a 30-day trial).

GitHub is a trademark of GitHub, Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with or endorsed by GitHub, Inc. or JetBrains.