Outgoing Webhook Integration

 

OverOps' outgoing webhook allows you to fully customize your alerts using raw event and threshold data flowing into an HTTP endpoint of your choosing.

In order to configure your outgoing webhook integration, click Settings, then Alerts, then navigate to Default Settings where you'll be able to configure and enable the integration:

 

You will need to implement an HTTP endpoint in a web-facing server in order to receive OverOps' outgoing webhook traffic. Once you do, enter its URL in the configuration dialog above.

Once you configure your webhook endpoint, OverOps will send a JSON message to that endpoint whenever an alert you configured gets triggered.

Below you'll find the full description of 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: {
...
}
}
}

api_version [string] The current API version: "0.2"
type [string] Message type. Currently "ALERT" only
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 secret key ID to which the alert pertains
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:

 

type [string] Either "NEW_EVENT", "RESURFACED" 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 [string] The username/email of the user 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
stacktrace [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

 

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

 

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:

 

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:

 

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: ...
}

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: [{
...
}, {
...
}]
}

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: "..."
}

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

 

Have more questions? Submit a request