Webhook execution logs
Webhook execution logs make Email This Issue for Jira administrators able to monitor which webhooks have been called upon which incidents, and whether the associated HTTPs requests have been dispatched successfully.
To see Webhook execution logs, go to WEBHOOKS --> Webhook Execution Logs.
If webhooks are called successfully the admins or all other addressed parties are informed about the source incidents through the preferred channel for which the webhook was configured.
If the webhook does not work properly, the incidents do not reach the receiving system, and are not reported there either. To learn about such an issue, check the logs of webhook executions. Issues with webhook call dispatching cannot be reported in the style of push notifications, they must be actively checked (polled) periodically.
On the listing page of webhook execution logs items are ordered by their time of execution, in a descending order starting with the latest items. There are 100 items per page. Assuming that only the most recent logs may refer to relevant, current issues, execution logs can neither be filtered, nor deleted. They are automatically purged after 90 days.
Each log entry contains the most essential details about the incident that triggered the webhook call and some additional information about the execution, especially in the event of failure, in order to make troubleshooting possible. As some fields may contain lengthy text (for example, error messages extended with stacktrace), these parts are displayed as collapsed by default, but they can be expanded one by one if needed.
When webhooks are called, all placeholders (i.e. Velocity variables) are replaced by their current value. In the execution log, the substituted parameters applied in the request are shown. Whether a template is correct or not can be easily validated upon a failed attempt to send a test notification.
The following attributes are revealed in a log entry:
Name
Refers to the webhook, whose execution this entity represents.
Yes
Event
The incident type (triggering event), for which the webhook was configured.
Yes
Entity name
The name of the entity (Incoming Connection, Outgoing Connection or Mail Handler), for which the incident occured.
Yes
Error message
The “message” value that was rendered in the request body. In most cases, this is the same message that can be found in the Error Queue of the failing component.
Yes
The time of execution
Timestamp indicating when this execution entity was created (with QUEUED status).
Note: Webhooks are executed in an asynchronous manner, typically within a few moments after their creation. If it tooks more, the webhook execution remains in QUEUED status until the actual dispatch.
Yes
Status
One of the following values
QUEUED : if created, but not yet executed
SUCCESSFUL : if executed successfully
FAILED : if executed, but failed
Yes
The service URL called
The final URL actually being called.
No
Webhook response
The HTTPs status code and message received from the remote endpoint (i.e. the response of the receiving service).
The response is parsed in a minimalistic way only, it is presented in a plain format (as received).
No
Executed Request Headers
The final generated Request Header that was sent with the request.
Note: Due to the peculiarities of the library being used for dispatching the HTTPs request, the Content-Type header is not listed here, but it is always included included in the real request headers with the value of application/json.
No
Executed Request Body
The final generated Request Body that was sent with the request.
No
Failure Reason
In the event of a failure (FAILED status), this attribute shows the root cause, potentially an error message and stacktrace.
If the webhook execution resulted in SUCCESS state (or still QUEUED), this field is hidden.
No
Last updated
Was this helpful?