Your data. Anywhere you go.

New Relic for iOS or Android

Download on the App Store    Android App on Google play

New Relic Insights App for iOS

Download on the App Store

Learn more

Close icon

Webhook weird problem with https end point


My endpoint url is http://username:password@domain/

When I click on ‘Save my changes’ button it shows “Your Webhook URL is not configured properly”. But, If I remove .do or then it saves and let me send the test message (but ofcourse I don’t receive that message because my interceptor is not called)

When I open the to public (so u/p is not required) then it starts working.

I am confused if I have to make this url public?


Hi @dagarwal82,

Our webhook service does not support basic authentication so a public URL would be needed.
For extra security, you could whitelist the webhook IP address block and if your service supports doing so.


Is it possible to implement a pagerduty like integration with newrelic Or is it too rigid and is something which only newrelic developers are supposed to do ?
I can not make the url public and do not have a control over firewall (It’s on a cloud where I do not have access to the infrastructure).

I do not want Email integration either.


Well, we do support a PagerDuty integration which will of course do the things you’d expect PD to do. But then you’d have to have & pay for a PagerDuty account.

We are not intending to duplicate the PagerDuty featureset (eg: re-escalation if the incident is acknowledged but not resolved) so our best advice there is to actually use PagerDuty, or as you are clearly trying to do, let us trigger some of your code to execute whatever business logic you have, via webhook.

If you could describe specifically what escalation/notification features are missing for you, we can advise what we can accomplish (for instance: we can at present send an SMS via email<->SMS gateway, and we can notify you about each new problem within a policy, if you configure the policy’s verbosity level as documented here: ).

Another possible workaround is to have your webhook receiver live somewhere free and public (eg: heroku - low traffic single-dyno apps are free) and then you can have that receiver which our system can access forward the notification into your system, since you’ll have access to full language capabilities for your app to do HTTP auth or whatever else needs be done to access your internal infrastructure.

We’ll definitely be filing a feature request about the things you’re missing, so please be specific so we can make sure that any future development has a chance of solving your base-level problem(s).


Great ! Yea, we do host a part of our app at Heroku. So, that looks a possible and wonderful workaround. Thanks :smile: