GitHub Projects Not Updating: Search and Issue Labels Delayed

What happened to GitHub Projects on September 23?

GitHub declared an incident on 23 September 2026 after receiving reports of degraded API request performance. During its investigation, GitHub reported that database replicas had detached, affecting the API, organisation creation and Projects.

GitHub subsequently restored the database replicas and reported that organisation creation and the broader GitHub API were no longer degraded. However, recovery for GitHub Projects continued separately. The service needed to process delayed information, leaving some Project search results and issue-label changes out of date.

The distinction matters because a successful update to an issue and the appearance of that update in a Project view are not necessarily the same event. A user may see the correct information on the issue itself while a search result or filtered Project view still reflects earlier information.

GitHub's incident timeline

These updates describe the incident at the times shown. They should not be treated as a permanent statement about GitHub's present availability. Consult GitHub Status for any subsequent mitigation or resolution notice.

Official sources: GitHub Status and incident updates and GitHub's September 23 incident discussion .

Which GitHub Projects features were affected?

GitHub's updates identified stale Project search results and a delay in issue-label changes appearing in Projects. These symptoms may make a Project look as though it is not updating even when an issue has already been edited successfully.

GitHub did not state that every Project item, every issue, or every repository was affected. Its incident updates identified particular delays in search indexing and the reflection of issue-label changes in Projects.

If you are experiencing a different symptom, such as a permission error or a failed automation run, investigate that problem separately rather than assuming it has the same cause as the incident.

Incident updates: GitHub Community incident thread .

Why are GitHub issue labels delayed in Projects?

During the incident, GitHub reported that issue-label updates were taking additional time to appear in Projects because a backlog of updates still needed to be processed.

At 17:01 UTC, GitHub said the delay could be approximately 10 minutes. The company also reported adding processing capacity to work through the backlog. Later updates said GitHub was investigating the continuing lag and preparing further mitigation.

The 10-minute figure was an incident observation, not a guaranteed maximum delay or a promised recovery time for every Project.

A practical example

Suppose you add the label bug to an issue. The issue page displays the new label, but your Project has a saved view that only shows items matching label:bug.

During an indexing delay, the issue may not immediately appear in that filtered Project view even though the underlying issue already has the label.

In that situation, repeatedly removing and reapplying the label may create unnecessary additional changes without addressing the delayed Project update. Confirm the source issue first, then check whether GitHub is still processing the incident backlog.

Is the issue label itself missing?

Open the issue directly from its repository and inspect the Labels field. If the correct label appears on the issue but not in the Project view, you have evidence that the issue and the Project display currently disagree.

If the label is missing from the underlying issue as well, inspect whether your change actually saved, whether you have permission to edit the issue, and whether a separate automation changed the label afterward.

Official incident report: GitHub Status . GitHub's documentation also explains how Project views filter items by issue labels .

Is the GitHub API down or are only Projects delayed?

The September 23 incident initially affected GitHub API requests. GitHub later reported that the database replicas had been restored and the broader API degradation had been mitigated.

Projects recovery took longer. GitHub continued reporting stale search results and delayed issue-label updates after the earlier API problem had been mitigated.

A delayed Project update does not, by itself, prove that the entire GitHub API is unavailable.

This distinction is particularly important for developers whose applications use GitHub's API to update issues and then query Projects to confirm the result.

How to tell the difference

An API request fails

Inspect the response status and error body. Check GitHub Status for any current API incident. Authentication, permission and rate-limit errors also require their own diagnosis.

The API request succeeds, but Projects still looks old

Check the source issue or pull request directly. A successful underlying change followed by stale Project search results is consistent with the indexing delay GitHub reported.

Only one Project view looks incorrect

Check its filters, item membership, permissions and saved view configuration. Do not assume that every display problem comes from the platform incident.

Should you retry every failed API request?

No. The correct response depends on the error and the operation being attempted. A temporary server error may justify a controlled retry with backoff, but an authentication or permission error generally requires correcting access rather than repeating the same request continuously.

Before retrying an operation that creates or changes data, establish whether the first operation may already have succeeded. Repeatedly creating Project items or applying changes without checking the existing state can produce unintended results.

Official sources: GitHub Status and GitHub's Project items REST API documentation .

What should you do if GitHub Projects is not updating?

Start by establishing whether your original issue or pull request was updated successfully. This allows you to distinguish a delayed Project display from a change that never saved in the first place.

1. Check the official incident status. Open GitHub Status and review the latest update. Check whether Projects indexing or label processing remains affected.
2. Open the issue directly. Navigate to the repository's Issues page and open the affected issue. Confirm its current title, labels and other relevant properties.
3. Compare the issue with the Project item. If the issue displays the correct information but Projects does not, note the difference before attempting another edit.
4. Check the Project view. Look for active label, status, assignee or repository filters that might hide the item independently of the incident.
5. Allow time for delayed indexing. If GitHub is still processing its backlog, avoid repeatedly changing labels solely to force a Project refresh. The approximate delay reported during the incident is not a guaranteed deadline.
6. Recheck after GitHub reports recovery. Once the incident is resolved, compare the issue and Project again. If the mismatch persists, collect the affected issue and Project URLs, expected result and observed behaviour.

How to check whether a Project filter is hiding your issue

GitHub Projects allows users to filter views by issue metadata and Project fields. These filters can explain why an item is absent even when the service itself is operating normally.

For example, a Project view using label:bug displays items that match the specified issue label. A view using label:bug status:"In progress" applies both a label condition and a status condition.

If an issue has the correct label but a different status value, it may be excluded from the second view. During the September 23 incident, delayed indexing created an additional possibility: the view might temporarily evaluate older label information.

A simple filter test

1. Record the current filter. Copy or note the existing filter before making temporary changes.
2. Remove unnecessary filter conditions. In a view you are permitted to inspect, temporarily clear the relevant filter to see whether the item is visible without it.
3. Check the issue's actual properties. Compare its labels, assignee and other relevant values with the filter requirements.
4. Restore the original filter. Do not leave a shared Project view changed merely for troubleshooting.

If the item appears without the filter but disappears when the filter is restored, verify whether the current issue data should satisfy that expression.

If the expected properties are present on the underlying issue but the view still behaves as though they are missing, the incident-related indexing delay may explain the difference.

GitHub documentation: Filtering projects .

What if your Projects automation or API integration is affected?

Teams may use GitHub Actions, third-party tools or custom integrations to add issues to Projects, change labels and update Project fields. During an incident, it is important to identify which part of a workflow actually failed or became delayed.

Check whether the underlying action succeeded

If your automation was meant to apply an issue label, inspect the issue directly to determine whether the label exists. If the label is present but the Project view is stale, repeating the label mutation is unlikely to address the underlying indexing backlog.

If the issue label is absent, review the automation's execution log, permissions and API response before making another attempt.

Do not confuse issue labels with custom Project fields

GitHub's Projects API treats issue labels as properties of the underlying issue. Labels are not updated using the same operation as a custom Project field such as a Project-specific text or status field.

GitHub's documentation states that the updateProjectV2ItemFieldValue mutation cannot directly change Labels, Assignees, Milestone or Repository. Those properties must be changed through the relevant issue or pull-request operations.

Consequently, an integration should not attempt to repair a delayed label display by treating the label as an ordinary editable Project custom field.

Handle retries carefully

For failed requests, inspect the returned status and error details before retrying. For operations that create or update Project items, check whether the intended change already exists so that a retry does not repeat an operation that was completed successfully.

If an automated workflow depends on immediately finding a newly updated issue through Project search, allow for a temporarily delayed result rather than treating every missing search match as proof that the original update failed.

Official API guidance: Using the API to manage Projects and REST API endpoints for Project items .

When will GitHub Projects return to normal?

GitHub's September 23 updates reported progress on the initial API degradation, followed by continued work to process delayed Projects search and label updates.

At 17:01 UTC, GitHub said it had added capacity to process the label backlog and expected that processing the full backlog would take additional hours. At 20:26 UTC, GitHub reported that it was preparing to deploy a further mitigation.

Those statements are progress updates, not a confirmed universal recovery time. The actual resolution should be determined from GitHub's subsequent official incident notices.

What to check after the incident is resolved

Issue labels

Confirm that recently applied labels appear on the underlying issue and are accurately reflected in Projects.

Project search

Search for a recently updated issue and compare the result with the current issue information.

Saved views

Reopen important filtered views and check whether their items match the current filter conditions.

Automations

Review workflows that failed or were paused during the incident. Reconcile the existing issue and Project state before rerunning data-changing steps.

If a particular Project remains out of date after GitHub confirms recovery, document the affected repository, issue and Project URLs, the expected result, and the actual result. Include relevant error messages if an API operation also failed.

This information can help distinguish an unresolved platform problem from an account-specific permission, configuration or automation issue.

The practical next step is to verify the underlying issue first, then compare it with the Project view and the latest official status update. You do not need to repeatedly edit an issue simply because its Project search result has not caught up.

For the latest incident state: GitHub Status . For the September 23 update history: GitHub's incident discussion .