Skip to content

Add Prometheus metrics export endpoint #15

@2214962083

Description

@2214962083

Summary

Prometheus is the de facto standard for metrics collection in modern infrastructure. Adding a /metrics endpoint that exports CronPulse data in Prometheus exposition format would allow users to integrate CronPulse into their existing Grafana/Prometheus monitoring stacks.

Problem

Users who run Prometheus + Grafana for infrastructure monitoring cannot pull CronPulse metrics into their existing dashboards. They have no way to create unified views that combine cron job health with other system metrics, set up Prometheus-based alerting rules, or track historical trends beyond what CronPulse's own UI shows.

Expected Behavior / Deliverable

  • A new API endpoint: GET /api/v1/metrics (or /metrics)
  • Output in Prometheus exposition format (plain text, not JSON)
  • Exported metrics should include:
    • cronpulse_monitor_status (gauge, 1=up, 0=down) with labels: monitor_id, monitor_name, group
    • cronpulse_monitor_last_ping_timestamp (gauge) — Unix timestamp of last successful ping
    • cronpulse_monitor_ping_total (counter) — total pings received per monitor
    • cronpulse_monitor_incidents_total (counter) — total incidents per monitor
    • cronpulse_monitors_total (gauge) — total number of monitors
    • cronpulse_monitors_up (gauge) — number of monitors currently up
    • cronpulse_monitors_down (gauge) — number of monitors currently down
  • Authentication via API key or Bearer token (should not be publicly accessible).

Implementation Hints

  • API routes live in: src/routes/ — add a new route file for the metrics endpoint.
  • Prometheus exposition format example:
    # HELP cronpulse_monitor_status Current status of the monitor (1=up, 0=down)
    # TYPE cronpulse_monitor_status gauge
    cronpulse_monitor_status{monitor_id="abc123",monitor_name="billing-sync",group="payments"} 1
    
  • No external library needed — the format is just plain text with a specific structure.
  • Query monitor data from D1 database to build the metrics response.
  • Consider caching the response in KV for a few seconds to avoid excessive D1 reads on frequent scrapes.

Acceptance Criteria

  • /api/v1/metrics endpoint returns Prometheus exposition format
  • All specified metrics are exported with correct types (gauge/counter)
  • Proper # HELP and # TYPE annotations
  • Endpoint is authenticated (API key or Bearer token)
  • Response is performant (KV caching if needed)
  • Documentation for Prometheus scrape config added
  • Unit tests for metrics serialization

Metadata

Metadata

Assignees

No one assigned

    Labels

    featureNew feature requesthelp wantedExtra attention is needed

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions