Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Redirect
filename
delay3
locationhttps://docs.meta-inf.hu/jeti-cloud/administration/alerting-via-webhooks/webhook-execution-logs

Thank you for visiting our old product documentation site. Note that we are in the process of migrating our product documentation and soon we will not 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.

Webhook Execution Logs make Email This Issue for Jira administrators able 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 following attributes are revealed in a log entry:

Attribute

Description

Column

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

Time of Execution

Timestamp indicating whenthis execution entity was created (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.

Yes

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

Yes

Service URL called

The final URL that was actually called.

No

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).

No

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“.

No

Request Body Executed

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

No

Failure Reason

In the event of a failure (

Status
colourRed
titlefailed
status), this attribute shows the root cause, potentially an error message and stacktrace.

Info

If the webhook execution resulted in

Status
colourGreen
titleSUCCESS
state (or still
Status
colourBlue
titleQUEUED
), this field is hidden.

No

...