doc.overops.com

Outgoing Webhook

OverOps allows you to fully customize alerts using raw event and threshold data flowing into the selected HTTP endpoint.

To configure your outgoing webhook integration:

  1. From Settings, click Alerts.
  2. From the Alert Settings, select Key Settings and then select the Webhook tab.
  3. To receive the outgoing Webhook traffic, implement an HTTP endpoint in a web-facing server.
  4. From the Webhook tab, enter the to receive the outgoing Webhook traffic URL to receive Webhooks.

Only admin users are authorized to change default integration settings.

Examples of Webhooks can be found here

Once the Webhook endpoint is configured, OverOps sends a JSON message to that endpoint whenever an alert you configured gets triggered.

The tables below, describe the different message structures:
JSON structure
All alerts have the following skeleton:

{
    api_version: "0.1",
    type: "...",
    date: ...,
    username: "...",
    service_id: "...",
    service_name: "...",
    data: {
        type: "NEW_EVENT",
        summary: "...",
        view_name: "...",
        added_by: ["..."],
        data: {
            ...
        }
    }
}
Field
Type
Description

api_version

string

The current API version: "0.2"

type

string

Message types are either "ALERT" or "TEST"

date

number

Timestamp in milliseconds at which the message was sent

username

string

The username/email of the secret key's owner

service_id

string

The username/email of the secret key's owner

service_name

string

The name of the secret key to which the alert pertains

The 'data' object represents the alert payload, and consists of the following:

Field
Type
Description

type

string

Either "NEW_EVENT" or "THRESHOLD", depending on the type of alert

summary

string

A human readable description of the alert, rendered by OverOps

view_name

string

The name of the view for which the alert was triggered

added_by

array

An array of usernames/emails of the user(s) that configured the alert

data

object

Variant payload per event type

New event payload structure:

{
    type: "...",
    location: {
        ...
    },
    entry_point: {
        ...
    },
    stacktrace: [{
        ...
    }, {
        ...
    },
    ...],
    link: "...",
    server_name: "...",
    app_name: "..."
}

type

string

One of "EXCEPTION", "LOG" or "HTTP_ERROR"

location

frame

The location in the code in which the event happened. See structure below

entry_point

frame

The transaction in the code in which the event happened. See structure below

stracktrace

array

An array of frames constituting the stack trace of the avent. See frame structure below

link

string

A web link to a root cause analysis of the error in OverOps

server_name

string

The name of the server on which the event happened

app_name

string

The name of the application in which the event happened

deployment_name

string

The name of the deployment in which the event happened

For events of type "EXCEPTION", the following fields will also be present:

Field
Type
Description

name

string

The name of the exception that was thrown

is_caught

boolean

Whether or not this exception was caught by user code or not

message

string

The exception message

For events of type "LOG", the following fields will also be present:

Field
Type
Description

level

string

One of "FATAL", "ERROR" or "WARN"

message

string

The error message that was written to the log

For events of type "HTTP_ERROR", the following fields will also be present:

Field
Type
Description

error_code

string

The error code received or sent by the HTTP framework, that triggered this event

message

string

The error message describing the error that triggered this event

Locations, entry points and stack traces are made up of frames, each with the following structure:

{
    class_name: "...",
    method_name: "...",
    method_desc: "...",
    full_name: "...",
    is_3rd_party: true/false,
    is_catch_frame: true/false,
    is_hit_frame: true/false,
    modification_timestamp: ...
}
Field
Type
Description

class_name

string

The fully qualified class name described in the frame

method_name

string

The name of the method described in the frame

method_desc

string

The method descriptor, in bytecode format, of the method described in the frame

full_name

string

A human readable rendition of the class name, method name and method descriptor

is_3rd_party

boolean

Whether or not this frame belongs to the user's code, or a 3rd party library/framework

is_catch_frame

boolean

For exceptions, whether or not the exception was caught in this frame

is_hit_frame

boolean

Whether or not this is the frame in which the event happened

modification_timestamp

number

Timestamp in milliseconds at which the code in this frame was last modified

Threshold alert payload structure:

{
    threshold: ...,
    times: ...,
    from_timestamp: ...,
    to_timestamp: ...,
    top_events: [{
        ...
    }, {
        ...
    }]
}
Field
Type
Description

threshold

number

The number defined by the user over which an alert is triggered

times

number

The number of times the errors which triggered this alert actually happened

from_timestamp

number

Timestamp in milliseconds at which the current alert window begun

to_timestamp

number

Timestmap in milliseconds at which the current alert window ended

top_events

array

An array of the top events that contributed to the threshold being reached. See structure below

Top event objects have the following structure:

{
    title: "...",
    frame: {
        ...
    },
    times: ...,
    link: "..."
}
Field
Type
Description

title

string

A human readable description of the event, rendered by OverOps

frame

frame

The location in the code in which the event occurred. See structure above

times

number

The number of times this specific event happened within the alert window

link

string

A web link to a root cause analysis of the event in OverOps

Open Source Example WebHooks

The below listed Webhooks are not supported and provided as is!