Incidents¶

In the context of Argus an Incident is an event where a monitor becomes unavailable, no matter the duration, the root cause or the kind of monitor affected by the unavailability.

Overview¶

On the incident overview page which can be opened from the left primary navigation, you can find a list of recent incidents affecting one of your monitors.

For each incident, you can open a detail page that contains additional information for each incident.

Details¶

We're recording the following details for each and every incident that is being detected by Argus:

• Affected Monitor
• Date and Time
• Root Cause
• Duration

Root Causes¶

If possible, our monitoring agents try to determine a root cause for an unavailability. Below, you can find an explanation of all possible root causes that can be displayed alongside an incident.

No Response¶

This root cause is primarily relevant for ICMP checks and indicates that our monitoring agents didn't receive an ICMP response package back from the monitoring target, hence considering the monitor being down.

Resolution Error¶

This root cause can only apply if the monitoring target is not an IP address, but rather a resolvable hostname or domain. The monitoring agents are trying to resolve the hostname before each and every check to guarantee an up-to-date check result.

Whenever an agent is unable to resolve the provided hostname via Cloudflare's 1.1.1.1 public DNS service and Google's Public DNS, the monitor is considered down and this root cause is being transmitted to Argus.

Timeout¶

This root cause is primarily relevant for HTTP checks and indicates that there was no answer from the server the agent has attempted to connect to, to send an HTTP request. It strongly suggests that the server is either completely unavailable or overloaded and hence not accepting any new connections.

Expected Status¶

This root cause is primarily relevant for HTTP checks. It indicates that the agent got an HTTP response to its request, but the HTTP response code is not included in the list of acceptable status codes that have been configured by the user within the monitor's configuration.

By default, all 2xx and 3xx status codes are accepted, unless explicitly changed.

Expected Headers¶

This root cause is primarily relevant for HTTP checks. It indicates that the agent got an HTTP response to its request, but the HTTP response didn't contain one of the expected headers that have been configured by the user within the monitor's configuration.

Expected Body¶

This root cause is primarily relevant for HTTP checks. It indicates that the agent to an HTTP response to its request, but the HTTP response body either didn't (or did) contain a certain keyword or regular expression, causing the response to be considered failing.

Comments¶

Every incident can be commented to record information on how it occurred and how it was resolved. Customers also use this feature for writing up reports on incidents later on where you might not remember the ins and outs of a downtime event.