Current main: applies to the application at 51a835a. See version and availability for newer candidate work.

Frequently asked questions

What is CPRa?

CPRa (Continuous Pulse and Recovery Agent) is a self-hosted monitoring and recovery agent written in Go. It runs health checks against services on a schedule, tracks incidents against failure and recovery thresholds, sends notifications, and runs a configured recovery action when a service fails. It ships as one static binary with an embedded read-only dashboard, an HTTP API, and the cpractl command-line client.

Is CPRa free and open source?

Yes. CPRa is licensed under the MIT license. The source is at github.com/ziad-hsn/cpra. There is no hosted service or paid tier.

What can CPRa check?

The default build checks HTTP, TCP, ICMP, DNS, UDP, TLS certificate expiry, Docker container state, and gRPC port reachability. Optional build tags add Redis, PostgreSQL, MySQL, MongoDB, RabbitMQ, and Kafka checks. See drivers and fields.

What does CPRa do when a check fails?

An initial failure can send a configured yellow notification. At the failure threshold, CPRa admits one eligible recovery operation. If no recovery is available, recovery fails, or healthy-check verification fails, it opens an incident and sends the configured red notification. The default build can restart a Docker container or call an HTTP webhook; optional build tags add Kubernetes rollout restart or scaling, EC2 instance reboot, and systemd unit restart. The incident closes after the configured number of consecutive healthy checks. See the incident lifecycle.

Where can CPRa send alerts?

Log, Slack, PagerDuty, email (SMTP with STARTTLS), generic webhook, Telegram, Discord, Opsgenie, Mattermost, VictorOps, Pushover, and Datadog in the default build; Microsoft Teams and Twilio with build tags. Destinations can be grouped; a group succeeds when at least one destination accepts delivery.

How does CPRa differ from a metrics stack like Prometheus?

CPRa is not a time-series database and does not store metric history. It performs active checks, decides whether a service is up, and acts on the answer. It exposes its own process and worker-pool state on a Prometheus-compatible /metrics endpoint, so it can sit alongside a metrics stack rather than replace one.

How does CPRa differ from an uptime monitor?

Uptime monitors typically stop at notification. CPRa also runs a recovery action you configure, with one attempt per incident and thresholds that must be met before the incident closes. The trade-off is that it is designed for a single process per configuration, not for a hosted multi-region service.

Does CPRa support high availability or clustering?

No. Run one process for a monitor configuration. Incident and delivery state is held in memory, resets on restart, and separate processes do not coordinate ownership. See behavior and limits.

Does CPRa keep history?

Not per monitor. The dashboard reports a healthy-sample percentage for the current process run and incident transitions are written to the configured log destinations, but there is no retained time series.

How is the dashboard secured?

The server listens on loopback by default. Binding to any other address requires an authentication token read from a file or environment variable; the browser login uses username cpra with the token as the password and the API accepts a Bearer token. The built-in listener serves HTTP, so remote access needs an HTTPS reverse proxy. See deployment.

What platforms does CPRa run on?

Release builds produce Linux amd64 and arm64 archives for the server and CLI, and the repository includes a Dockerfile for a container that runs as UID 1001. Building from source needs Go 1.25 or later; rebuilding the dashboard needs Node.js 24 and pnpm.

How do I install it?

Follow the quickstart: build, copy the example manifest, set a service address, run ./bin/cpra -yaml monitors.yaml, and open http://localhost:8060.

Where does the name come from?

"CPR" is the pulse line: the agent keeps taking the pulse of a service and resuscitates it when it flatlines. The lowercase "a" is "agent". The gold loop in the mark is a nod to Ra, the sun that makes the same circuit every day.

Are persistence, native services and the Go SDK available on main?

They are documented as separate candidates. Main still resets incident state on restart and exposes read-only v1. The release candidate adds local persistence and native operations. The SDK and approved management plan include proposed v2 writes and external workers, whose server implementation and publication are pending.

How do I change the appearance?

Use the dashboard Settings page to choose System, Light or Dark. System follows your operating system. The documentation header cycles the same three choices. Both preserve explicit preferences across reloads.