We recently updated our repository to use the latest version of the Netlify app for GitHub, so that we could get preview deploy checks reported on our PRs.
The preview builds are deploying fine, but the checks do not report “successful” on the PR on GitHub - they only report as “completed”.
I have set up the deploy notifications to add rich commit info on both success as well as failure. Any idea how to get GitHub to recognize when a preview deployment has succeeded?
Hi @mdlincoln, the one that is staying yellow is actually a Github Commit Status notificiation (Deploy notifications | Netlify Docs). Can you check that you have one set up for that as well?
Also, I’ve updated the title of the post to be more accurate.
Thanks - I believe I’ve got github commit status notifications set up now. This is now how the checks report:
The first deploy/netlify status is still there, and still reports as “waiting for status to be reported”?
A link to the PR in question: a new dummy PR for netlify by mdlincoln · Pull Request #1606 · programminghistorian/jekyll · GitHub
I’ve now tried completely deleting the site and re-creating it from scratch, leaving all the default notifications intact:
Making a brand new PR after this still results in a successful deploy but incomplete github commit checks:
@Dennis do you have any ideas why a completely fresh Netlify site using the default configuration would still not be reporting successful commit statuses?
@Dennis this is still a problem, even for brand new PRs! Is there anything currently missing in our configuration that would be causing this?
For anyone else stuck with this: currently we’re using a workaround on the GitHub side: only requiring the netlify/ph-preview/deploy checks on our branch protection rules, and not the misbehaving netlify/deploy checks:
Hi, @mdlincoln, and thank you for your patience with this.
When I checked this site, I don’t see a notification for “deploy succeeded” as being one of the notifications configured.
I know you have a workaround in place now but if you are willing to test adding the success notification would you please let us know if it works? Here is a screenshot of the notification missing:
If this doesn’t resolve the issue when tested, please let us know and we’ll keep troubleshooting.
Sorry to hijack this thread. It seems Netlify is not using the Github Deployments API correctly.
I run https://checklyhq.com and we trigger specific actions based on Github Deployment hooks.
This works perfectly for deployments done by companies like Zeit and Heroku. However, Netlify seems to not trigger the correct deployment status updates as per the Github API, Deployments - GitHub Docs
I would love for our customers to use Checkly on their Netlify deployments, but there is no way for us now to find out when a deployment is finished.
We don’t use the github deployments API at all, Tim. That’s not a bug, it’s how we intend to roll 
I have added your voice to the feature requests that we DO use that API, but there is no work planned to do so.
To others who may run into this issue: this could be due to account-level commit status notifications, which you can find here (swap out YOUR-TEAM with your team name ):
https://app.netlify.com/teams/YOUR-TEAM/settings/sites#notifications
If you run into this hanging “deploy/netlify” status, try changing the setting there to “One notification per repo”
Hi @jen
sorry to bump this old post but I’ve searched in the forum, and this seems to be the thread which relates to my problem now
If the problem is account-level, how come sites under the same account and team behave differently?
deploy/netlify status works fine for axway-open-docs.netlify.app and streams-open-docs.netlify.app, but not for open-docs-microsite-template.netlify.app/
cc @perry
Update - I’ve discovered that this specific notification in this site was stuck because you must enable ‘Add Deploy Preview notifications to commits when Deploy Preview succeeds’ notification in https://app.netlify.com/sites/<your-site>/settings/deploys#deploy-notifications. Once I did this, the item has passed on the list.
Thank you so much for updating this thread, @amussap. I am glad this is resolved and working for you now 
I’m having the same problem, does this solution happen to work on a mono repo? What happens if there are concurrent builds, would this solution only send one notification?
Hey there, @sedghi 
Great question! It really would depend on how it is configured. You can read more about notifications for monorepos in our Docs!
Having a similar issue at the moment. For the past couple of weeks, “Retry Deploy” action in Netlify doesn’t update the commit status in GitHub PRs. The commit status is only updated when new commits are pushed to the PR, but this is often not necessary, as the issue is often config- or CMS-based rather than a code issue.
The Deploy Preview for the latest commit in this PR completed successfully, but the Netlify-added commit statuses weren’t updated.
Hi Ezra,
I’m not entirely surprised to hear that. I’m not sure if that is a bug or is intended by our implementation, but we will check in with our dev team on that for you and let you know what we find out! To set expectations it may take some time for us to get to this research request - a couple weeks potentially since the team we’ll need to work with is a bit out of pocket next week.
Hi @fool
We have the same issue, any update on that one?
I remember it use to work months ago.
This is updated correctly when we trigger a retry on Netlify:
Hey Quentin,
Good detail that it used to work - I wasn’t too sure about that.
In the escalation I filed back in September for this thread, our dev team allowed that it would be good for our platform to try to connect all the details better for retried deploys, but it turns out that there are some hard problems to solve in there (largely edge cases, but with a customer base in the millions, even “infrequent edge cases” lead to dozens of reports pretty quickly).
I think it’s in their backlog now, but I don’t expect work on it in the immediate future, sorry to say.
Thank you for the feedback!
It is not a critical feature just a “good to have”, we like to ensure everything is “green” before merging our PRs.
Happy to see that it may work again in the future!
