is there an "enhanced WebHook" alternative for robust notifications (with retries, timeout, etc.)?

[llagos]

Mornin'!

We've been using WebHooks for a while, to send updates (state changes, comments added) from JSD to our Call Center. Now, we need to create tickets from JSD to the Call Center system (inhouse CRM-like system). We plan to use WebHooks again, but the problem we're foreseeing is error handling, timeouts, retries, etc.

So far, the default WebHooks implementation doesn't even give a proper error handling mechanism. For instante, is the WebHooks is fired, it will show "success" on the GUI (no log), but if the remote endpoint is down, it will still show "success" (because it was fired, no matter what happened at the other end).

This of course is nonsense for us. We need a robust, flexible, and smart notifications mechanism that could tell us at least if the other end is down, got a timeout, etc.

So, big question... what do you use for this? is there a plugin you could recommend? Something else?

Thanks a lot!

[Steffen Opel _Utoolity_]

We are using the Send outgoing web request action of Code Barrel's Automation for Jira for this purpose.

The app has an audit log to assist with debugging rules, and failed request properly show as errors there (at least for all request failures I've observed so far), alongside a few details about the error. The rule owner can receive an email  notification on error either 'once when rule starts failing after success', or 'every time this rule fails'.

Code Barrel also provides a comparison regarding Automation for Jira vs Service Desk automation that may help you to evaluate the benefits and cost of switching to their solution.

Alternative via Amazon Web Services

If you happen to use AWS, you could also use the Automate with AWS then action of our Automation with AWS (Jira) app to decouple the sending and receiving of Jira Service Desk events, for example by using the Put CloudWatch Events action (example payloads).

• Disclaimer: I'm a co-founder of this app's vendor Utoolity.

This approach would allow you to simply ingest the event into an Amazon EventBridge event bus (recently rebranded from CloudWatch Events), and then use a rule to match applicable JSD events and trigger an AWS Lambda function that invokes the actual request to your webhook recipient.

Like this you can benefit from the advanced monitoring and observability features AWS provides, so you can get as fancy with reporting and handling errors as your use case requires, for example:

• Rather than triggering the Lambda function directly, you could have a rule to convert the JSD event into an SQS message, and then subscribe a Lambda function to the SQS queue. The message will then remain in the queue until your Lambda function successfully delivers the webhook according to your retry and timeout needs.
• For starters, you could also use our Invoke Lambda Function or Send SQS Message actions right from Jira Service Desk btw., but given your increased reliability needs, I wanted to point out a potentially more robust architectural pattern.

Please note that, other than Automation for Jira, we do not provide a dedicated audit log within the host product, so you would still be constrained to the JSD audit log limitations in case an automation rule fails on the Jira side of the request already (which is considerably less likely when calling an AWS API, but can still happen when you have a misconfiguration in the JSD rule itself for example).