We also have a monorepo. This bug is causing my team to think CI isn’t working. Even in a normal repo, changes to, for example, internal documentation will trigger this bug.
As a temporary fix, we are avoiding this by adding ignore = "/bin/false" to the [build] section of our netlify.toml, forcing the build to proceed even if there haven’t been any changes in the front end. This works for us because we don’t have a huge merge volume, but it wouldn’t work for a team with a larger number of merges because it would eat into their build minutes.
+1 same issue as dmorda
The +1 has been added to the feature request, @nic.
+1 this – would like to see this updated as well!
+1 for me too, working in a monorepo.
1 Like
+1, also using a monorepo
1 Like
+1 here. I’m working with a pretty large scale monorepo of which Netlify is only used for a few of the web applications and I would love to see this feature come to light to prevent false negatives of these application’s statuses 
1 Like
Hi @jimmyh,
Thank you for that. The feedback has been passed on. If/when anything changes, we’d update the thread.
1 Like
Another +1. Almost 2 years on, seems like a lot of votes have been registered in favor of this change. How many more are needed to make this a priority?
hey there @Janosh , i totally hear what you are saying! i am going to try and get some fresh info on this, and i’ll update this thread when i do.
Hi, @Janosh. About this:
How many more are needed to make this a priority?
There is no simple answer to this and there is no specific number that is the tipping point. Generally speaking, the more people that +1 a feature request the more likely it is to be created. In the simplest terms, this feature request does need more +1s before it will be created.
So, we do encourage people to post here if they want to see this feature added and if that happens we will post an update here to let you know.
1 Like
Another +1. This happens for Slack notifications and causes a lot of anxiety on our team when builds start failing. I know it seems like the smallest thing, but when we have processes around failing builds this can cause a lot of heartache. The only alternative for us is to turn off failing build notifications, but that’s not the best vibes either.
If there’s no suitable workaround for this issue could it get a bump in priority? I love Netlify, but it’s a hard sell to use it over CircleCI or Vercel to folks when we don’t have the control to go fix it ourselves. Thanks!
1 Like
Hi @mwood23,
Thank you for adding your voice. We’d post an update if/when anything changes in this regard.
Another +1. The badge in its current form is more harmful than useful. A deploy without changes to the published content is not a deployment failure. It is a pretty common situation, for example when updating documentation, configuration files, scripts, or tools in repositories that contain publishable content. If Netlify would simply deploy the content, the operation would be a success. The auto-cancellation by Netlify is simply a performance optimization on Netlify’s end that should be transparent to Netlify’s users. I hope you prioritize and fix this soon.
1 Like
Hey there, @kevlar 
We appreciate your patience here. We do not have an update yet. That being said, we have added your voice to the open issue. I know this isn’t the answer you were hoping for, and we will follow up on this thread when something changes!
Another +1
I agree with @kevlar - the current badge is more harmful than useful. I’ve just built a dashboard to allow my team to see the status of each site, and they want to know why some have failed to deploy when in reality the deploy was cancelled due to no actual changes in the tree (we’re using a monorepo).
Hey there, @mhgibbons
Thanks so much for taking the time to give us these details. I have shared your direct feedback with our Product team!
Another +1
To be honest its just ugly the failed status.
1 Like
Hey there, @kauly
I have added your thoughts to the open issue with our Product team. Thanks for chiming in.