Monitoring API

GET /api/monitoring/metrics returns your fleet's current state in Prometheus exposition format. It is the pull half of Monitoring > Integrations, and it is the whole machine-readable API surface aethercert exposes to your own tooling.

Requires the Pro plan or an MSP tier.

Issuing a key

Create a key under Monitoring > Integrations. It is shown once, in the form <key-id>.<secret>, and is sent as a bearer token:

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

A key is scoped to the organization that issued it and can be revoked at any time; revoking takes effect immediately. Only the hash is stored, so a lost key is replaced rather than recovered.

Authentication is rate-limited per key id - 240 requests per 5 minutes, sized for a 15-to-60-second scrape interval. The response is never cached; a scrape sees the fleet's current state.

Wiring it up

CheckMK ships a built-in Prometheus special agent, so pointing that at this URL with the key as its bearer token is the entire CheckMK setup - there is 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:

scrape_configs:
  - job_name: aethercert
    scheme: https
    metrics_path: /api/monitoring/metrics
    authorization:
      credentials: "<key-id>.<secret>"
    static_configs:
      - targets: ["api.aethercert.com"]

Your monitoring server needs outbound HTTPS to api.aethercert.com. Nothing has to be opened on the agent side for this.

What it exposes

What it deliberately does not expose

The endpoint reports aggregate counts, never per-certificate or per-agent detail. A certificate's common name is not visible to a metrics scraper, and no metric carries an agent id or a job id as a label - an unbounded label set would be a cardinality problem as well as a disclosure one. For per-entity detail, use the dashboard.

Alerting on it

Three rules cover most of what goes wrong:

groups:
  - name: aethercert
    rules:
      - alert: AethercertCertificateExpiringSoon
        expr: aethercert_certificates_expiring_within_days{days="14"} > 0
        for: 1h
      - alert: AethercertJobsFailing
        expr: aethercert_jobs_total{status="failed"} > 0
        for: 15m
      - alert: AethercertAgentsOffline
        expr: aethercert_agents_total{status="offline"} > 0
        for: 30m

For event-driven alerting rather than polling, use the push integrations instead.