PrometheusAlert: a webhook forwarding hub for Prometheus, Zabbix, Grafana and Graylog alerts

What PrometheusAlert solves, and who ends up running it

Alertmanager already routes and groups alerts. What it does not do is speak DingTalk, WeCom, Feishu, Tencent Cloud SMS, Aliyun voice calls, Huawei SMS, Baidu SMS, Ronglianyun phone calls, 7moor SMS or voice, Telegram, Baidu Hi, or Kafka. PrometheusAlert exists to sit between those two worlds. The README describes it as an alert center message forwarding system that accepts messages from Prometheus, Zabbix, Graylog2 and Graylog3, Grafana, SonarQube, Aliyun CloudMonitor and any system exposing a webhook, then renders each message through a custom template and sends it to one or more receiving targets.

The audience is narrower than the feature list suggests. This is a tool for operations teams whose notification channels are Chinese cloud providers or Chinese chat platforms. If your team lives in Slack and PagerDuty, the channel matrix in this project is mostly dead weight. If your team runs DingTalk and buys Aliyun SMS credits, the same matrix is the reason to pick it over writing your own relay in an afternoon.

The project is not archived. Its last push was on 2026-07-23, and the most recent release is v5.0.0 from 2026-07-20, with v4.9.2 in 2025-11-20 and v4.9.1 in 2024-06-19 before that. The release cadence is uneven: roughly eighteen months between v4.9.1 and v4.9.2, then eight months to v5.0.0. Plan upgrades around that rhythm rather than assuming continuous churn.

The webhook in, template render, channel out data flow

The README states the mechanism plainly: a custom template endpoint at /prometheusalert receives messages from monitoring systems or anything with a webhook, the message is rendered into text through a custom template, and the result is forwarded to different receiving targets. That is the whole pipeline. There is no queue broker in the middle and no agent on the monitored host.

The repository layout matches that description. The backend uses the beego framework and the front end uses the AdminLTE template based on Bootstrap and jQuery. Top-level directories separate cmd, conf, controllers, db, doc, example, models, routers, static and views, plus a PrometheusAlertVoicePlugin directory and a zabbixclient directory. The zabbixclient entry is worth noting: Zabbix integration is not just a generic webhook receiver, there is a client component in the tree.

Templates are stored in a database, not only in files. The feature list says MySQL, SQLite3 (the default) and PostgreSQL are supported as template storage, which the README frames as making clustered deployment easier. The Dockerfile confirms the default: it copies db/PrometheusAlertDB.db into /opt/PrometheusAlertDB.db and copies the db directory into the image. A single-node deployment therefore starts with a SQLite file baked into the container.

Two features change the shape of the flow. Alert groups let you write notification media into a group so configuration and modification happen in one place. Alert routing plus alert records let you view alert history on a page and operate on message routing, and the same records can be written to Elasticsearch 7.x and 8.x for viewing in Kibana. That means the relay can also be an audit log, but only if you configure ES.

Installing PrometheusAlert and sending a first alert

The README lists three paths: build from source, download a release, or run the Docker image. All three are documented, so pick based on how much of the config you want to own.

For a source build, the README says application information and build commands live in the Makefile, and asks that make, git and go be installed. The default build output is ./PrometheusAlert. The quick-start sequence copies the example config, runs the app, and checks health:

cp conf/app-example.conf conf/app.conf
go run main.go
curl http://localhost:8080/health

If you prefer a release tarball, the README gives the Linux amd64 URL for v5.0.0 and the commands to fetch and unpack it. After unpacking you run ./PrometheusAlert directly, or nohup ./PrometheusAlert & for a background process. The web interface then answers on http://127.0.0.1:8080, and the README notes that the default login account and password are configured in app.conf. For process supervision, the repository ships example/supervisor/prometheusalert.ini. To send logs to the console instead of a file, the README says to set logtype=console in app.conf.

Docker is the shortest path because app.conf values can be seeded from environment variables. The prefix must be PA_, followed by the configuration key name, with every hyphen in the key replaced by an underscore. Environment variable matching is case-insensitive. The README's example starts the container like this:

docker run -d \
-p 8080:8080 \
-e PA_LOGIN_USER=prometheusalert \
-e PA_LOGIN_PASSWORD=prometheusalert \
-e PA_TITLE=PrometheusAlert \
-e PA_OPEN_FEISHU=1 \
-e PA_OPEN_DINGDING=1 \
-e PA_OPEN_WEIXIN=1 \
feiyu563/prometheus-alert:master

After the container is up, the README says to open http://localhost:8080. The dashboard includes configuration testing, custom alert message templates and template testing, so the first real use is to paste a sample payload into the template tester, render it, and confirm the text that would reach DingTalk or Feishu. Only then point a real webhook at /prometheusalert. Note what the README says about scope: for DingTalk, WeCom and Feishu bots you can skip app.conf entirely, but SMS, phone and email require the relevant app.conf keys to be configured first. If you only ever use chat bots, the config file is nearly empty, and that is by design.

Where PrometheusAlert gets in the way

The dependency list in go.mod is the clearest statement of cost. It pins beego v1.12.1, which is an old major line of a framework that has since moved on. It pulls in the Aliyun, Baidu and Elasticsearch v7 SDKs directly, plus go-sqlite3, lib/pq, go-sql-driver/mysql, sarama for Kafka, and telegram-bot-api v5. Every one of those is a channel you may not use but still compile, ship and eventually patch. A team that only needs DingTalk is carrying Aliyun, Baidu, Tencent and Elasticsearch client code in the same binary.

SQLite as the default template store is a real constraint. The README presents MySQL and PostgreSQL as the path to clustered deployment, which implies the default single-file database is not the clustered path. If you run two replicas against the same SQLite file on shared storage, you are outside what the documentation describes.

There is a subtler failure mode in the forwarding model itself. The feature list mentions random polling for ddurl, fsurl and wxurl: when multiple URLs are configured, the default is to send to all of them, and enabling the option picks one at random, explicitly to avoid sending too frequently and triggering a bot's message interception. That is a workaround for rate limiting, not a queue. If a target is down when the relay forwards, there is no retry mechanism documented in the README, and no dead-letter queue appears in the feature list. The alert is simply gone, and the only trace is the alert record if you enabled the database or ES storage.

Finally, the README is in Chinese and the documentation site is a GitBook. The README does not document rollback, and it does not describe a migration path for the template database between major versions. Upgrading from v4.9.2 to v5.0.0 is a release-note question, not a README question.

PrometheusAlert compared with Alertmanager receivers and Grafana alerting

The honest alternative for a Prometheus-only shop is Alertmanager's own receiver configuration. Alertmanager already owns grouping, inhibition, silences and retry with backoff, and it has a webhook receiver that can call anything, including PrometheusAlert. The difference in approach is where the template lives. Alertmanager templates are Go template files mounted next to the config; PrometheusAlert templates live in a database and are edited through a web dashboard with a test button. If your platform team edits YAML in Git, Alertmanager is the shorter path. If your on-call rotation edits notification wording in a browser, PrometheusAlert's model fits better.

Grafana alerting is the other overlap, and it is a genuine one. Grafana can evaluate rules and send notifications to contact points without any relay, and the related-search data shows people comparing the two. The difference is source coverage. Grafana alerting covers what Grafana can query. PrometheusAlert is a receiver: it takes whatever Zabbix, Graylog2, Graylog3, SonarQube or Aliyun CloudMonitor sends over a webhook and normalizes it. If your alert sources are heterogeneous and include a logging system, a relay is the only place where they converge.

A third option is writing a small relay yourself. A Go service that accepts a JSON webhook and posts to a DingTalk robot is a few hundred lines. What you would then reimplement is the part PrometheusAlert already ships: per-channel signing and credentials for Aliyun, Tencent, Huawei, Baidu, Ronglianyun and 7moor, the phone number rotation and date-based routing, the alert group abstraction, the ES record writer and the voice plugin. That list is the actual product.

Licence, maintenance and what an upgrade actually costs

PrometheusAlert is MIT licensed. That is permissive: you can use it commercially, modify it and redistribute it, provided the copyright notice and permission notice are preserved. The repository ships a LICENSE file at the top level. Nothing here is legal advice, and the MIT text itself is the authority on what you may do.

Maintenance is best judged by the push and release record rather than by any claim. The last push was on 2026-07-23. The v5.0.0 release landed on 2026-07-20, three days earlier, after v4.9.2 on 2025-11-20 and v4.9.1 on 2024-06-19. A major version bump from 4.x to 5.x is the kind of change that usually carries configuration or template implications, and the README does not describe them. Read the 5.0.0 release notes before upgrading, and test the template rendering after, not before.

The upgrade cost is dominated by the configuration surface. conf/app-example.conf is the reference for every key, and the documentation has a separate page per channel: DingTalk, Feishu, WeCom, WeCom app, Aliyun, Tencent, Ronglianyun, Huawei, Baidu, email, 7moor, Telegram, Bark, Baidu Hi, Elasticsearch records, voice, Feishu app, Kafka and alert groups. If you have enabled four channels, an upgrade means re-checking four groups of keys. There is a hot reload configuration interface listed in the feature set, which suggests you can change configuration without a restart, but the README does not say which keys it covers. Verify that against doc/readme/hotreload.md before relying on it during an incident.

Editorial conclusion

Adopt PrometheusAlert if you already run Prometheus, Zabbix, Grafana or Graylog and your notification targets are Chinese cloud services, DingTalk, WeCom, Feishu or Telegram, because the per-channel configuration and template rendering are already written. Do not adopt it if you only need email from Alertmanager, or if you cannot run a stateful service that stores templates in SQLite, MySQL or PostgreSQL. Before rollout, verify that conf/app.conf in your build matches the environment variable names you plan to pass, and that the /prometheusalert endpoint returns the rendered text you expect for your own payload.

Frequently asked questions

Official sources

1. feiyu563/PrometheusAlert on GitHub
2. License: MIT
3. Project website
4. README
5. Releases