Monitoring integrations

Monitoring > Integrations connects aethercert to a monitoring system, SIEM or SNMP receiver you already run. There are two independent halves: push integrations aethercert sends alerts to as they happen, covered here, and a metrics endpoint your own tooling pulls from.

Both require the Pro plan or an MSP tier. Configuring them is an admin or owner action, the same as a deploy target - a member can see what is configured but not change it.

The three sinks

aethercert only ever sends an SNMP trap. It runs no SNMP agent of its own, so there is nothing to poll or walk.

Webhook

One field: the http(s) URL. Set an HMAC secret and every request carries

x-aethercert-signature: sha256=<hex digest of the raw body>

computed with HMAC-SHA256 over the exact bytes of the body. Verify against the raw body, not a re-serialized copy.

The URL you give is customer-supplied, so the request goes through the same SSRF guard as every other outbound fetch in the product, including a connect-time re-check against DNS rebinding.

Syslog / CEF

SNMP trap

The payload

Every sink formats the same canonical alert into its own wire format - JSON for a webhook, a CEF extension for syslog, varbinds for a trap.

{
  "event_type": "certificate.expiring_soon",
  "severity": "warning",
  "occurred_at": "2026-09-06T12:00:00.000Z",
  "organization_id": "<organization-id>",
  "resource": { "type": "certificate", "id": "<certificate-id>" },
  "message": "\"app.example.com\" expires within 14 days"
}

severity is info, warning or critical. resource is null for an event that is not about one object.

What gets delivered

A curated subset of the event log is pushed - the events worth paging on. Routine bookkeeping is not, because a feed carrying every certificate rename would bury the failures.

Alert-worthy events include: a job or a deployment failing after its retries, an agent going offline and coming back, a certificate expiring within 14 days or already expired, a certificate revoked, an agent enrolled or deleted, a certificate authority or deploy target created, changed or deleted, a CA connector denying or replaying a sign request, a CRL or CA certificate expiring or expired, an unreachable CDP, an ESC6 finding, a fleet update that failed or rolled back, and an issuance notification that exhausted its retries.

Testing and delivery status

Send test delivers one synthetic alert synchronously, so you can confirm the receiver is reachable and correctly configured without waiting for a real event.

Each integration shows the outcome of its last delivery - success or failure, when, and a short error. A failed delivery is not retried. A persistent failure is worth checking: wrong host, an expired collector certificate, a revoked credential. Delivery runs after the event is already recorded, so a slow or broken receiver never delays or fails the operation that produced the event.