Monitoring & the event log

Certificate automation only helps if you find out when it stops working. aethercert records what happened in three places, at three different levels of detail, and (on Pro and MSP) can also push or expose that information to a monitoring system you already run.

The event log

Every issuance, renewal, deployment and administrative action is appended to an organization-wide log with its outcome. It is append-only: there is no edit or delete, including for owners.

What is recorded

Each entry carries a timestamp, an actor (a user, an agent, or the system), an action, the object it affected, and a human-readable message.

Retention

The window is set by your plan, and it is enforced twice: the page will not show you anything older, and a nightly job physically deletes it.

Deletion is real. If you need a longer trail than your plan keeps, export what matters before it ages out - and see Plans and limits for what changes with an upgrade.

Job history

Manage > Jobs is the operational view: every issue, renew and revoke attempt, its state, and its error text if it failed.

Jobs retry automatically up to three times before they are marked failed, so a single transient DNS or network error resolves itself without anyone looking. A job that reaches failed has genuinely failed three times - see Troubleshooting.

Watching for expiry

View > Certificates is sorted by expiry, which makes the certificate closest to lapsing the first thing on the screen. That covers both kinds of record:

• Managed certificates renew themselves, so one approaching expiry means renewals are failing - look at its jobs.
• External certificates cannot renew. They are listed precisely so their expiry dates are visible somewhere; acting on one means either renewing it the way it was originally issued, or creating a managed certificate for the same names to take it over.

Agent connection health

View > Agents shows when each agent last checked in. An agent that has gone quiet has not necessarily failed - it may simply be idle on its plan's default 3-hour cadence

• but one that has missed several intervals is worth looking at.

The usual causes, in order of likelihood: the service is not running, the host cannot reach the control plane outbound over HTTPS, or the agent was revoked. See Troubleshooting.

Email notifications

Monitoring > Email Notifications optionally sends an email through your own mail infrastructure the moment a certificate is successfully issued - typically so another team can pick it up for manual deployment on a system aethercert does not manage itself. It is not used for aethercert's own system email.

Configure one or more mail apps (Microsoft 365 or SMTP, credentials held in the Vault, never returned by the API); how many you can add depends on your plan. Pick a mail app - and up to 10 recipients - on a certificate job or a certificate policy to enable its notification. Every attempt, successful or not, is kept in the notification history on the same page.

An MSP Plus portal reuses the same mail apps for messages to its customers - see Plans and limits.

Integrations

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

Metrics endpoint (CheckMK, Prometheus, Grafana, and anything else that speaks it)

GET /api/monitoring/metrics returns your fleet's current state in Prometheus exposition format: agent counts by status, certificate counts by status, how many certificates expire within 7/14/30 days, job counts by status and type, how long it has been since any agent last checked in, how much of your fleet's check-in traffic is idle versus actually fetching work, and how long jobs take to process once claimed. Issue a key under Monitoring > Integrations, then point your tool at it with Authorization: Bearer <key>:

curl -H "Authorization: Bearer <key>" https://api.aethercert.com/api/monitoring/metrics

CheckMK ships a built-in Prometheus special agent, so pointing it at this URL with the key as its bearer token is the whole CheckMK setup - no plugin to install. The same endpoint works unchanged with Grafana, Datadog's OpenMetrics check, Zabbix's HTTP agent, or a plain prometheus.yml scrape config. A key is scoped to the organization that issued it and can be revoked at any time; revoking takes effect immediately.

The endpoint deliberately reports aggregate counts, not per-certificate or per-agent detail - a certificate's name is not exposed to a metrics scraper. For per-entity detail, use the dashboard itself.

Push integrations: webhook, syslog/CEF, SNMP trap

The other half is event-driven: a curated set of alert-worthy events - a certificate expiring within 14 days or expiring, an agent going offline or checking back in, a job failing after its automatic retries, an agent being removed, or a certificate authority being added, changed or removed - is delivered to whatever you configure, as it happens.

aethercert only ever sends an SNMP trap - it does not run an SNMP agent of its own, so there is nothing to poll or walk.

The webhook JSON body (and the fields carried in the CEF extension / SNMP varbinds) is the same canonical shape either way:

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

severity is one of info, warning or critical. Each integration can filter by a minimum severity and by event type, so a webhook only meant for critical paging does not also receive routine fleet-membership notices.

Use Send test on a configured integration to deliver one synthetic alert synchronously and confirm the receiver is reachable and correctly configured, without waiting for a real event. A delivery's outcome - success or failure, and when - is always shown next to the integration; a failure does not retry automatically, so a persistent one is worth checking (wrong host, expired certificate, revoked credential).

Configuring where aethercert's outbound traffic goes is an admin/owner action, the same as a deploy target - a member can see what is configured but not change it.

Logs on the agent host

Agents and CA connectors keep their own log files locally. That is where the detail lives which the event log deliberately does not carry - the exact output of a reload command, the path a file was written to, the raw error from a DNS provider's API.

Local retention is distinct from the dashboard's event log window. Changing your plan takes effect on the next check-in, including downward: an agent configured for 90 days on Pro is clamped to 30 immediately on a downgrade to Standard, without anyone editing it.