Peekaping: a Go and React uptime monitor you run yourself

What Peekaping is, and the problem it targets

Peekaping is a self-hosted uptime monitoring system. You point it at websites, APIs and other endpoints, and it tells you when they stop responding, through alert channels and status pages. The README frames the project as an alternative to Uptime Kuma and states the motivation directly: the author used Uptime Kuma, respects it, and wanted to address what the README calls systemic limitations that appear when teams scale monitoring and try to integrate it into DevOps processes.

The intended audience is stated in the README as professional DevOps teams. That shows up in the feature list rather than in marketing language. There is a REST API that the README says exposes all system functions, API key management with access control, and a community Terraform provider published at registry.terraform.io/providers/tafaust/peekaping. A team that provisions its monitoring the same way it provisions its load balancers is the target here, not someone who wants to click through a wizard once and forget it.

The monitor list is broad for a project at version 0.0.46. HTTP/HTTPS, TCP, Ping (ICMP), DNS, push webhooks, Docker containers, gRPC and SNMP are all listed, alongside checks for PostgreSQL, Microsoft SQL Server, MongoDB, Redis, MySQL/MariaDB, MQTT, RabbitMQ and Kafka. That is a wider set of protocol-level checks than most small monitoring tools ship with, and it is the strongest argument for picking this over a generic HTTP pinger.

The Go server, the React client, and where the API sits

The repository is a pnpm and Turbo monorepo. The root package.json defines workspace scripts such as dev:api, dev:producer, dev:worker and dev:ingester, and the Makefile points at apps/server for the Go binary and apps/web for the frontend. Those four dev scripts are the clearest signal about the runtime shape: the API, a producer, a worker and an ingester are separate processes rather than one monolith. The README describes the server as written in Golang for low RAM and CPU use, and the client as React with TypeScript for static typing.

The API-first claim is architectural, not a marketing line. If every function is reachable over REST, then the web UI is one client among several, and a CI pipeline or a Terraform provider can be another. That is the real difference from tools where the UI is the product and the API is whatever the UI happens to call. It also means the API surface is a compatibility commitment: the roadmap lists multi-user access levels as unchecked, so today the API key model is the access control story.

Storage is pluggable. The README lists SQLite, PostgreSQL and MongoDB, and the repository ships separate Dockerfiles and compose files for each: docker-compose.bundle.sqlite.yml, docker-compose.bundle.postgres.yml and docker-compose.bundle.mongo.yml, plus a set of prod and dev variants. The Makefile defines DEFAULT_DEV_DB and DEFAULT_PROD_DB, both set to mongo, which tells you which backend the maintainer exercises by default. If you plan to run SQLite, you are on a supported path but not the default one.

Installing Peekaping with Docker and SQLite

The README's quick start is a single docker run against the bundled SQLite image. It maps port 8383, sets DB_NAME to a file inside the container, and mounts a host directory at /app/data so the database survives a restart. Copy it as written.

docker run -d --restart=always \
  -p 8383:8383 \
  -e DB_NAME=/app/data/peekaping.db \
  -v $(pwd)/.data/sqlite:/app/data \
  --name peekaping \
  0xfurai/peekaping-bundle-sqlite:latest

After the container starts, the web interface is on port 8383 of the host. The README links separate documentation pages for the PostgreSQL and MongoDB setups at docs.peekaping.com, so if you need either of those, follow those pages rather than adapting the SQLite command.

If you prefer compose over a bare run, the repository carries docker-compose.bundle.sqlite.yml at the top level, and the Makefile exposes dev, prod and standalone targets per database. The README does not document the first-run account flow, so the initial admin credentials are something to confirm against docs.peekaping.com before you expose the port.

Beta status is the first thing to weigh

The README carries an explicit beta warning. It says the software is still under active development, that some features could change, and that the author recommends testing in non-production environments first. That is unusually direct, and it should be taken literally. Version numbers agree: the most recent release listed is 0.0.46, published on 2026-04-10, with 0.0.45 on 2025-12-21 and 0.0.44 on 2025-10-29. A 0.0.x series with roughly two-month release spacing is a project still finding its shape.

The roadmap reinforces this. Incidents, a migration tool from Uptime Kuma, multi-user groups and access levels, monitor grouping, and Gatus-like conditions are all listed as unchecked. Two of those matter for adoption decisions. Without an incident model, you get alerts and status pages but not the incident record that a postmortem or an SLA report needs. Without the migration tool, moving existing Uptime Kuma configuration means recreating monitors by hand.

There is also a gap between the README's monitor list and the roadmap. The roadmap lists HTTP keyword and JSON query checks as unchecked, so an HTTP monitor today confirms reachability and status code, not response body content. If your health check depends on matching a string in the response, that is not in the shipped feature list. The last push to the repository was on 2026-05-24, so the codebase has moved since the 0.0.46 release, though the README does not describe what landed after it.

Alert channels, status pages, and what is not there yet

The notification list is long: Email over SMTP, Webhook, Telegram, Slack, Google Chat, Signal, Mattermost, Matrix, Discord, WeCom, WhatsApp via WAHA, PagerDuty, Opsgenie, Grafana OnCall, NTFY, Gotify, Pushover, SendGrid, Twilio, LINE, PagerTree and Pushbullet. That covers most of what a team already uses, and it means you rarely need to write a custom integration to get paged.

On top of that, the README lists status pages, SVG status badges, multi-factor authentication, brute-force login protection and SSL certificate expiration checks. The badges are worth noting: an SVG endpoint you can embed in a README or a dashboard is a small feature that decides whether a status page gets looked at.

The notification roadmap is where the gaps are. Microsoft Teams, Rocket.Chat, DingDing, AliyunSMS, ClickSend SMS and CallMeBot are all unchecked. If your organization runs on Teams or Rocket.Chat, you are looking at a webhook bridge until those land. The same pattern applies to monitors: Steam, GameDig and Playwright are planned but not present. The README does not document rate limits or retry behaviour for alert delivery, so how a channel behaves during an outage of the channel itself is unstated.

How it compares to Uptime Kuma and the hosted alternatives

Uptime Kuma is the direct comparison, and the README names it as the project Peekaping was built to improve on. The difference in approach is the API. Uptime Kuma is a Node.js application with a UI-first design; Peekaping is a compiled Go server with a REST API the README says covers every function, plus a Terraform provider for infrastructure-as-code workflows. If your monitoring config lives in a repository and gets reviewed like other infrastructure, that distinction is the whole argument. If you configure monitors once by hand, it buys you little.

The other names in this space take different shapes. OneUptime bundles monitoring with incident management and on-call, so it answers the incident gap that Peekaping's roadmap still lists as open, at the cost of running a larger stack. Openstatus leans toward hosted status pages rather than a self-hosted agent you own. Statping-ng and Cachet are older status-page-centered tools. AutoKuma is not a monitor at all; it generates Uptime Kuma configuration, so it solves a different problem. Kener is a status page project rather than a full monitoring server.

Peekaping's position is narrow and clear: a self-hosted Go monitor with a real API and a wide protocol list, without the incident and on-call layers. That is a reasonable place to sit, as long as you know that is where you are sitting.

Licence, maintenance and upgrade cost

Peekaping is MIT licensed, and the LICENSE file sits at the top level of the repository. MIT is permissive: you can use, modify and redistribute it, including in commercial settings, provided the copyright notice and licence text are kept. That is the general shape of the licence, not legal advice for your situation.

The practical cost is upgrade churn. At 0.0.x, the README warns that some features could be changed, and semantic versioning gives no stability promise below 1.0. The repository ships a CHANGELOG.md and a MIGRATION_SETUP.md, and the compose files are split by database, so an upgrade means pulling a new image tag and confirming your schema and config still work against whichever backend you chose. The bundled images use supervisord configuration files (supervisord.bundle.sqlite.conf and siblings) to run multiple processes in one container, which means the all-in-one image is convenient but not the same as running the API, producer, worker and ingester separately.

The last push was on 2026-05-24. That is recent enough that the project is not abandoned, but the README's own beta warning and the 0.0.x release line are the facts to plan around: pin an image tag rather than tracking latest, and keep the SQLite data directory backed up if you use the bundled setup.

Editorial conclusion

Peekaping fits a team that wants an API-first monitor it can drive from CI or Terraform, and that is willing to run beta software on infrastructure it can afford to restart. It does not fit anyone who needs incident management or a migration path off Uptime Kuma today, because the roadmap lists both as unchecked. Before adopting it, verify the monitor types you actually depend on against the list in the README, and check whether the Terraform provider under registry.terraform.io/providers/tafaust/peekaping covers the resources you need, since it is community-maintained rather than part of the repository.

Frequently asked questions

Official sources

1. 0xfurai/peekaping on GitHub
2. License: MIT
3. Project website
4. README
5. Releases