Skip to content


ExaCheck reads from a YAML or JSON configuration file containing the list of checks. By default, the configuration file will be loaded from /etc/exabgp/exacheck.yaml. If the configuration file extension is json, the file will be loaded as a JSON file rather than YAML.

Base Structure

A (minimal) configuration schema looks like this:


# The list of health checks

  - name: Example DNS Service
    description: Perform a basic SOA query for to If the query returns a response, would be advertised with BGP.
      method: dns
      host: # Note DNS queries are being sent to which should be bound to loopback
    nexthop: self

# An optional list of notification targets

  - name: Microsoft Teams Example
    description: This target will only receive route withdraw/announce events.
    url: msteams://organisation/TokenA/TokenB/TokenC/

Configuration Keys

The following top level configuration keys are available:

Key Type Default
exacheck Dict undef
checks List[Check] undef
logging Optional List[LogMethods] undef
notifications Optional List[Notifications] undef
sentry Optional Dict undef


The exacheck key contains the various internal configuration for ExaCheck. Configuration to enable/disable live reloading and the monitoring interval can be adjusted using this key.

For the list of available configuration options sett the ExaCheck internal configuration page.


The checks key contains a list of the health checks that should be executed. For the configuration of individual checks see the health checks configuration page.


The logs key contains a list of log targets. These may be file based or remote syslog (UDP/TCP) servers. For configuration options see the logging configuration page.


The notifications key contains a list of notification targets. See the notifications configuration page.


Sentry error reporting/profiling can be configured with the sentry key. See the Sentry configuration page.


The configuration file is validated using Pydantic. The configuration file is parsed into a dictionary from YAML or JSON which is then loaded into the Pydantic model.

Validation is as strict as possible while also being safe - ExaCheck will not start if the configuration is invalid and live reloads are skipped if the configuration becomes invalid.

Configuration Schema

A JSON schema for the configuration is available in schema.json. Alternatively the schema can be generated by the command line interface directly.

The JSON schema can be used by certain IDEs (VS Code as an example) to validate the configuration as you edit it. It can also be used to visualize the list of available options using a tool such as JSON Crack.

VS Code

If using VS Code with the YAML Language Server the following header may be set in the configuration file:

# yaml-language-server: $schema=