Peekaping: An API-First Uptime Monitor in Go, Still in Beta
Open Source Uptime Kuma Alternative
At a glance
- What is it?
- Peekaping is a self-hosted uptime monitoring stack written in Go with a React frontend, positioned as an Uptime Kuma alternative with a REST API at its centre. The monitor and notification lists are long, but the project labels itself beta and ships a roadmap of unfinished features, so the adoption decision turns on how much you need that API surface today.
- Who is it for?
- Adopt Peekaping if you need programmatic control over monitors and notifications, are comfortable running beta software, and can pin a specific image tag rather than :latest. Do not adopt it if you need incidents, multi-user access levels or a migration path from Uptime Kuma, all of which sit unchecked on the roadmap.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 114 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Peekaping targets: monitoring as an API, not a dashboard
Most self-hosted uptime tools are configured by clicking. That is fine until you have forty services and want the checks to be created by the same pipeline that deploys them. Peekaping's README states the project was built because its authors used Uptime Kuma and wanted to address what they call systemic limitations around scaling and integration. The stated approach is API-first: all system functions are described as accessible through a RESTful API, so monitor creation and notification configuration can be driven by scripts or infrastructure tooling rather than a browser session. The audience named in the README is professional DevOps teams, and the supporting signal is a community Terraform provider published on the Terraform registry under the tafaust namespace. That is the concrete case for the project: if your monitoring configuration belongs in version control next to the services it watches, a typed API is a different proposition from a UI-only tool. If you configure five checks once and forget them, the API buys you very little.
How the pieces fit: Go server, React client, three database backends
The repository is split into a Go server and a React plus TypeScript frontend. The README frames the Go choice as a resource argument: a compiled language with low RAM and CPU consumption, which matters when the monitor count grows. The frontend is typed, and the README presents static typing as a reliability property rather than a developer convenience. Storage is pluggable across SQLite, PostgreSQL and MongoDB, and the badge row at the top of the README lists all three. That flexibility has a cost the README does not discuss: three supported backends means three sets of documented setup steps and, in practice, three code paths to keep correct. The extensibility claim is that new monitor types and notification channels can be added without modifying the system core, which is a modularity statement rather than something a reader can verify from the README alone. The monitor list is broad and leans toward infrastructure rather than web-only checks: HTTP/HTTPS, TCP, Ping, DNS, gRPC, SNMP, Docker container, MQTT, RabbitMQ, Kafka, and direct database checks for PostgreSQL, MySQL/MariaDB, MongoDB, Redis and Microsoft SQL Server. Push monitors accept incoming webhooks, which covers cron jobs and batch processes that cannot be polled.
Getting it running with the SQLite Docker image
The README gives a single Docker command for the SQLite path, and it is short enough to quote exactly:
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
The image is 0xfurai/peekaping-bundle-sqlite, the container listens on port 8383, and the only environment variable shown is DB_NAME, pointing at the database file inside the mounted volume. The volume mount is the part worth reading twice: without it, the database lives inside the container and disappears when the container is replaced. The README links separate documentation pages for PostgreSQL and MongoDB setups at docs.peekaping.com, and those are the pages to read if you are not using SQLite, because the quick start above does not cover them. The README also notes the image tag as :latest, which for a project that publishes 0.0.x releases is a poor default for anything you care about; pinning to a specific version tag is the safer pattern, though the README does not demonstrate that. The bundle image name implies the web frontend and API ship together rather than as separate containers, but the README does not describe the internal process layout, so treat that as an inference from the image name rather than a documented fact.
Notification channels: breadth as the integration story
The alerting list is where Peekaping's scope becomes clear. It covers the expected set (Email over SMTP, Slack, Discord, Telegram, PagerDuty, Opsgenie, Pushover, Gotify, NTFY, Mattermost, Matrix, Google Chat, Signal, Twilio, SendGrid) and then keeps going into territory that many self-hosted monitors skip: WeCom, WhatsApp via WAHA, Grafana OnCall, PagerTree, Pushbullet and LINE Messenger. For a team whose on-call tooling is already decided, that breadth is mostly irrelevant; you need one channel to work reliably. For a team in a mixed environment, or one that has to reach users on LINE or WeCom, the list removes a piece of glue code you would otherwise write. Two channels are absent and appear on the roadmap instead: Microsoft Teams and Rocket.Chat. If either is your primary notification path, Peekaping is not the tool for you yet, and the README is explicit about that. The roadmap also lists WhatsApp via Whapi, CallMeBot, AliyunSMS, DingDing and ClickSend SMS as future work.
The beta label is the real constraint, not a disclaimer
The README carries a beta notice with four bullet points, and they are worth taking literally: the software is under active development, some features could be changed, the author recommends testing in non-production environments first, and issues should be reported. That is an unusually direct statement of maturity, and it should shape how you read the rest of the page. The roadmap reinforces it. Incidents, a migration tool from Uptime Kuma, multi-user support with groups and access levels, group monitors, Homepage widget support and Gatus-like conditions are all listed as unchecked. The migration tool matters most for the target audience: the README positions Peekaping against Uptime Kuma, but there is no shipped path to bring existing monitors across, so an evaluation means recreating configuration by hand or through the API. Multi-user access levels being absent also sits awkwardly beside the README's claim of built-in API key management and access control at what it calls enterprise level; API keys and role-based user management are not the same thing, and only the former is described as present. The version numbers tell a related story: 0.0.46 is the most recent release listed, and the jump from 0.0.45 in December 2025 to 0.0.46 in April 2026 suggests a slow, deliberate release cadence rather than rapid iteration.
Where it fits against Uptime Kuma and Gatus
The obvious comparison is Uptime Kuma, which Peekaping names directly and credits. The difference the README argues for is architectural: Uptime Kuma is treated as the incumbent whose configuration model does not lend itself to automation, while Peekaping exposes a REST API as the primary interface and publishes a Terraform provider for declarative management. The second comparison the README invites is Gatus, not by name in the marketing copy but in the roadmap, which lists Gatus-like conditions as unfinished work. Gatus takes the opposite stance to Peekaping on configuration: checks are defined in a YAML file rather than created through an API or a UI, which makes the config reviewable in a pull request but means the running system has no source of truth other than the file. Peekaping's API-first model supports the same workflow through Terraform, at the cost of a running server that must be reachable before the configuration can be applied. Neither approach is strictly better; they fail differently. If your monitoring config must be readable without a running server, YAML wins. If monitor state needs to change in response to events, an API wins. Peekaping has chosen the second, and the beta status means you are adopting that choice before it has settled.
Maintenance, upgrades and the MIT licence
Peekaping is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive baseline and removes the licensing question from most adoption decisions, but MIT says nothing about whether the project will keep receiving releases, and the README offers no support commitment or release policy. The practical maintenance burden has three parts. First, the database: SQLite is a single file, so backups are a file copy, while PostgreSQL and MongoDB add a service to run and upgrade. Second, the image tag: the quick start uses :latest, so an unattended docker pull can move you between 0.0.x releases without warning, and the beta notice explicitly warns that features can change; pinning a version tag is the mitigation, though the README does not show it. Third, the roadmap: features listed as planned may arrive in a form that differs from what you built around, and the migration tool from Uptime Kuma, when it lands, will itself need testing against your existing configuration. None of this is legal advice; if you redistribute Peekaping or a modified version, read the licence text rather than this summary.
Editorial conclusion
Adopt Peekaping if you need programmatic control over monitors and notifications, are comfortable running beta software, and can pin a specific image tag rather than :latest. Do not adopt it if you need incidents, multi-user access levels or a migration path from Uptime Kuma, all of which sit unchecked on the roadmap. Before committing, verify that the monitor types you actually rely on behave as documented, and read the docs page for your chosen database rather than assuming the SQLite quick start generalises.
Community notes