CircleCI 2.0 notifications/webhooks



Is there any news about notification/webhook functionality(“call” a webhook on successful deploy) in CI 2.0?
I’ve checked reference and haven’t found anything connected with it.


Hi Max,

The same experimental config syntax should actually work in 2.0 builds, as well—see this Discuss thread.

Perhaps we should document this better… Thanks for bringing this up!


We have this syntax in our version 2 config and it does nothing. :frowning:


@brainsik Hmm… Are you a paid customer? If so, please open a support ticket with a link to your build so we can investigate.

If not, can you post your config.yml here so I or someone else at CircleCI (or someone from the community!) can take a look?



@rose Our project is open source. We are currently on the free tier as the project ramps up. You can also see the hack I’ve implemented as a stop gap to get notifications about master branch failures.


Mmm, I see, thanks! Have you tried your config with the experimental block at the top instead of at the bottom?

If that didn’t/doesn’t help, I will add this report to our ticket that’s currently tracking issues with this syntax on 2.0.



This is a misleading post and should be removed. I’ve been told by support that V2 does not support notifications.


Related: Webhook support removed from documentation? Still supported?


Except that it does.

We are getting building notifications out of our Circle 2 builds using the 1.0 syntax:

    - url: https://host/webhook/

I’d like to see this as an officially supported feature, as build notifications are essential for a build system.

The misleading parts are the claim:

  1. 2.0 doesn’t support webhooks. They are currently working with the notify: key in the config.yml
  2. That the experimental per-branch hooks are the only way to fly.
  3. That the experimental notifications are the same a proper webhook. That feature is designed to filter chat notifications, not enable build automation.

This feels like a documentation bug to me - the notify key should be documented in 2.0. The alternative, which is that it’s no longer a supported feature is completely unacceptable in a build system.:angry:


Hi there,

@delprofundo Apologies for the confusion on this issue!

And @arigesher, glad to hear that these notifications are still working for you in your 2.0 projects! I completely agree with you that this is an essential feature and should be documented first-class.

Right now, using this syntax on 2.0 seems to be flaky—it’s working for some folks, and not for others. Which is not ideal! And thus it probably should not be documented until we can clearly support it.

We are looking into the situation and will update y’all as soon as we can! Please do feel free to continue reporting back on your experiences using this feature, positive or negative—the data will help guide Engineering as they investigate.


So currently there is not a documented, consistently working, officially supported way to do build automation with 2.0?

That seems like an urgent situation to fix.


Depends on how many customers are using it, I guess, and moreover, how many of those customers are non-free tier. I have a fairly involved CI setup, and I don’t use notifications.


How does the non-free tier change things?


Sorry @arigesher, I should have expanded on that remark. What I meant was that the internal prioritisation of a bug/feature in any product team depends on how it affects paying customers, and how many paying customers are affected.

I would imagine Circle have product manager(s) who are juggling several hundred competing demands on engineering time, and they have some internal data that indicates how important each thing is. For example, one of the above contributors wanting this to work is a F/OSS customer, and while they are undoubtedly valued by Circle, they don’t generate any income, and are thus not a priority. That’s OK - I am a free-tier user also, and I am most grateful for the excellent features/resources I do get.


OK, yeah, that makes sense.

For what it’s worth, I’m a paying customer but this seemed like a good discussion to have in public.


Oh yes, I quite agree - I don’t mean to attenuate the discussion. My only point is that as users, we don’t see all the data, and that product managers are not wilfully keeping issues in the backlog in order to annoy us :wink:

closed #17

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.