Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Webhook Execution Logs make Email This Issue for Jira administrators possible to monitor, which webhooks have been called upon what incidents and whether the associated HTTPs requests have been dispatched successfully.
In a typical setting, if webhooks are called successfully, the admins - or all other addressed parties - are informed about the source incidents via the preferred channel, for which the webhook was configured. On the other hand, if the webhook itself does not work (properly), the incidents neither will reach nor will be reported in the receiving system, so the only way to learn about such an issue is to check the logs of webhook executions. Apparently, issues with dispatching the webhook calls cannot be reported in style of push notifications, they must be actively checked (polled) every now and then.

The listing page of webhook execution logs has a simple, pretty fixed structure: the logs are ordered by their time of execution, in a descending order (i.e. with the latest on top), 100 items per page.
Assuming that only the most recent logs may refer to the most relevant (and still exisiting) issues, the 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 some failure, in order to make the 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 upon need.

Info

At the time, when webhooks are actually called, all placeholders (i.e. Velocity variables) are replaced by their current value. In the execution log, the substituted parameters actually applied in the request are shown, and as such, the correctness of templates can be easily validated upon a failed attempt to send a test notification.

The following attributes are revealed in a log entry:

...

Attribute

...

Description

...

Webhook

...

Refers to the webhook, whose execution this entity represents.

...

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.

...

Incident Trigger ID

...

This is the identification of the internal exception that resulted in the event triggering the Webhook.

...

Service URL called

...

The final URL that was actually called.

...

Request Headers Executed

...

The final generated Request Header that was sent with the request.

Due to the pecularities 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“.

...

Request Body Executed

...

The final generated Request Body that was sent with the request.

...

Webhook Response

...

The HTTPs status code and message received from the remote endpoint (i.e. the response of the receiving service).

Info

The response is parsed in a minimalistic way only, it is presented in a plain format (as received).

...

Time of Execution

...

Timestamp of creating this execution entity (with

Status
colourBlue
titleQUEUED
status).

Info

Webhooks are executed in an asynchronous manner, typically within a few moments after their creation. If it tooks more, the webhook execution reamains in

Status
colourBlue
titleQUEUED
status until the actual dispatch.

...

Entity

...

This is the name of the entity (Incoming Connection, Outgoing Connection or Mail Handler), for which the incident occured.

...

Status

...

One of the following values

  • Status
    colourBlue
    titleQueued
    : if created, but not yet executed

  • Status
    colourGreen
    titlesuccessful
    : if executed successfully

  • Status
    colourRed
    titlefailed
    : if executed, but failed

...

Failure Reason

...

Status
colourRed
titlefailed

...

Expertisefinder redirect
forcedfalse
typeurl
dest{"value":"https://docs.meta-inf.hu/jeti-cloud/administration/alerting-via-webhooks/webhook-execution-logs"}
enabledtrue

Thank you for visiting our old product documentation site. Note that we no longer store or update our documentation here.

Please navigate to our new documentation site and update your bookmarks accordingly. If you're looking for the former content of this page, click here.