API mixed-severity assertions
46-monitoring-per-assertion-severity.yaml
HTTP(S)
What this example does
Monitoring integration: API mixed-severity assertions. Shows how to report checks to existing operational monitoring.
Checks and behavior
- Sends an GET request to https://api.example.com/health.
- Checks allowed/denied HTTP status codes.
- Validates required, forbidden or matching HTTP headers.
- Looks for expected response content and/or rejects known error markers.
- TLS settings cover certificate trust.
- Applies response-time thresholds for operational alerting.
- Formats results for icinga2 output.
Adapt example domains, addresses, credentials and thresholds to your environment before use.
YAML configuration
# Copyright (c) 2026 mati peterson. Maintainer: mati peterson <ipsonic@mailbox.org>. Project: https://ipsonic.com/probe/. Disclaimer: Provided AS IS, without warranty of any kind. Use at your own risk; validate checks and configurations before production use.
name: "API mixed-severity assertions"
url: "https://api.example.com/health"
request:
method: GET
timeouts:
connect: 3
response: 5
tls:
verify: true
monitoring:
service_name: "API Health"
output: icinga2
on_failure: critical
assertions:
- contains: "Missing header: X-Request-ID"
severity: info
- contains: "Body does not contain 'healthy'"
severity: warning
- contains: "HTTP 503"
severity: critical
thresholds:
response_time:
warning: 2
critical: 4
tests:
status:
allow: [200]
headers:
exists: [Content-Type, X-Request-ID]
body:
contains: [healthy]