praeco: a web GUI for building ElastAlert 2 rules

A front end for a rule engine you still have to run

Praeco is an alerting tool for Elasticsearch, and the README is precise about what it is: a GUI for ElastAlert 2, using the ElastAlert API provided by elastalert-server.

That distinction is the whole design. ElastAlert 2 is the component that watches Elasticsearch and fires alerts, and it is configured in YAML. Praeco is the component that helps a person write that YAML, and it does so by talking to elastalert-server, a separate service that exposes the ElastAlert API over HTTP so a web application can drive it.

The features list describes what a person gets. You build alerts interactively with a query builder, you preview the results in an interactive chart, you test an alert against historical data before it goes live, and you can see logs of when your alerts check, fire and fail. The chart preview and the historical test are the two that change how alerting feels, because they turn a rule from a piece of YAML you hope is right into something you can look at.

The rule types are the ElastAlert set, covering Any, Blacklist, Whitelist, Change, Frequency, Flatline, Spike, Cardinality, New Term and Metric Aggregation.

The notification destinations are where the list gets long: Slack, Email, Telegram, Jira, Mattermost, Command, Gitter, Amazon SNS, Amazon SES, Zabbix, Twilio, PagerTree, Exotel, GoogleChat, Stomp, Splunk On-Call, ServiceNow, Chatwork, Discord, TheHive, Alerta, Datadog, Rocket.Chat, PagerDuty, Tencent SMS, Dingtalk, Alertmanager, OpsGenie, Graylog GELF, Lark, IRIS, WorkWechat, Matrix Hookshot, Microsoft Power Automate, Webex, YZJ, Flashduty, LINE Message API, SMSEagle, and an HTTP POST endpoint.

One condition is worth repeating. The project is completely free under GPLv3, and in return the README asks that you fill out a short survey about how you use it.

The project is looking for a maintainer

The first thing in the README is a callout marked IMPORTANT, and it is a governance notice rather than a technical one: Praeco is looking for a new maintainer, with an email address given for anyone interested.

The FAQ expands on what that means in practice, and the list is unusually blunt. Please understand that this is open source software, and if you need generous support, please consider paid support software. We are not responsible for fixing bugs. There is no obligation to respond to your request. There is no obligation to add features. And we do not always answer issues.

There is also a MAINTENANCE.md file in the repository root, next to the UPGRADING.md and CREDITS.TXT files, so the project has written down its own position rather than leaving it to be inferred.

The release history shows the project is still moving. Version 1.8.25 is dated 2026-04-05, 1.8.26 on 2026-09-22, and 1.8.27 on 2026-10-07, with the last push to the repository on 2026-10-20. So this is not an abandoned codebase, it is an active one looking for someone to own it.

For an adopter that distinction matters. A tool whose maintainer is stepping away is a tool you may end up maintaining, and the honest way to evaluate it is as a well-built piece of software with a maintenance risk attached, rather than as a supported product.

Four commands to a running Praeco

The quickstart runs the app with Docker compose, and the README says Praeco includes everything you need to get started once you provide the IP address of your Elasticsearch instance.

mkdir -p rules rule_templates
chmod -R 777 rules rule_templates
echo "slack_webhook_url: ''"  | sudo tee -a rules/BaseRule.config >/dev/null
export PRAECO_ELASTICSEARCH=<your elasticsearch ip>
docker compose up

The two directories have to exist and be writable before the containers start, which is why the mkdir and chmod come first, and the base rule configuration file is created with a Slack webhook placeholder so that the ElastAlert server has something to read.

The environment variable is the Elasticsearch address, and the README is emphatic about one detail: do not use 127.0.0.1 for PRAECO_ELASTICSEARCH, with a pointer to the first item in the troubleshooting section. That is not a preference, it is a container networking fact. The compose file adds an extra host entry that maps the hostname elasticsearch to whatever address you put in the variable, and 127.0.0.1 inside the container is the container itself.

Notification settings such as API keys go in rules/BaseRule.config, and the application is then available on http://127.0.0.1:8080. One useful property of that file is that any ElastAlert 2 option you put into it is applied to every rule, so it is the place for shared settings rather than per-rule configuration.

Upgrading pulls the latest image unless you pin it

The upgrade notes are short, and they describe a workflow that differs from what most people expect.

If you use the docker-compose.yml published on GitHub as it is, it refers to the current latest version rather than a specific version. If you want to specify a version, you edit the file yourself and then run docker compose up with the force-recreate and build flags.

The sequence for moving to a new version is explicit:

docker compose down
docker rmi praecoapp/praeco:latest
docker rmi praecoapp/elastalert-server:latest
docker pull praecoapp/praeco:latest
docker pull praecoapp/elastalert-server:latest
docker compose up --force-recreate --build

Removing the images before pulling matters because the compose file refers to the latest tag, and a cached local image of that tag will otherwise be reused rather than refreshed.

The README also warns that you may need to update your config files when a new version comes out, and points at UPGRADING.md for version-specific instructions. That is the document to read before running the upgrade, not after, because a configuration change that breaks a running alert engine is discovered at three in the morning by someone who did not read the release notes.

The two images are published on Docker Hub under the praecoapp organisation, one for Praeco itself and one for the elastalert-server, and the wiki links a table of how those image versions relate to each other, which matters when the two need to be kept in step.

The compose file shows the two service architecture

Reading the compose file is the fastest way to understand how the pieces fit, and it is short.

The elastalert service runs the praecoapp/elastalert-server image, publishes ports 3030 and 3333, and mounts four things: the ElastAlert configuration as config.yaml, the API configuration as the server's config.json, and the rules and rule_templates directories. It also declares an extra host entry mapping the hostname elasticsearch to the address in PRAECO_ELASTICSEARCH, which is the mechanism behind the warning about 127.0.0.1.

The webapp service runs the praecoapp/praeco image, depends on the elastalert service, publishes 8080, and mounts the public praeco.config.json along with two nginx configuration files, one for the main server and one for the default site. A commented-out environment block shows a VUE_APP_BASE_URL setting for hosting the app under a sub path.

The Dockerfile explains how the front end is built. It starts from node:24.21.0-bookworm, installs nginx, and sets NODE_OPTIONS to the openssl legacy provider, which is the usual workaround for older webpack style builds on a modern Node. There is a dependencies stage that runs npm install, and a release stage that copies the node_modules across, copies the source, runs the build, and copies the dist output into the nginx web root. The image exposes 8080 and its entrypoint is entrypoint.sh.

So the web app is a static Vue bundle behind nginx, and the alerting engine is a separate container with the ElastAlert API on it. The user interface never talks to Elasticsearch directly for the alerting side; it goes through the server.

Four configuration files, and a Vue 2 front end

Advanced configuration is spread across four files, which the README lists explicitly: rules/BaseRule.config, config/api.config.json, config/lastalert.yaml, and public/praeco.config.json.

The last of these holds the settings that are specific to the Praeco application itself, and the README shows three of them. The appUrl links back to your Praeco instance and is used in Slack alerts. The errorLoggerUrl points at a recordatus instance for JavaScript error reporting, which is a third party project by the same author for collecting front end errors. And hidePreconfiguredFields lists fields to hide when editing rules because they are already filled in from the template.

The front end stack is worth noting if you plan to contribute. The package is Vue with the 2.7 line, built with Vite, and the component library is Element UI at 2.15.14, with vue-echarts and echarts 5 for the charts, vue-query-builder for the query builder, cron-ui and prettycron for the schedule editor, prismjs with a Vue wrapper for the code viewer, and axios for the API calls.

The repository also carries the test and lint setup. Unit tests run with vitest, end to end tests run with Cypress through run_tests.sh, and there is a separate test:coverage script. Linting is ESLint over src, and the build tooling is Vite with a vitest.config.js and a vite.config.js. A .browserslistrc and a .nvmrc pin the browser targets and the Node version the project expects.

One dependency is worth flagging for a self-hosted install: prettycron is pulled from a GitHub fork rather than the registry, and vue-query-builder is referenced the same way in the truncated part of the manifest, so a build depends on those sources being reachable.

Elasticsearch version support, and where the boundary of the GUI sits

The FAQ answers the version question in detail, and the answers are not uniform.

Elasticsearch 5.x is not supported. Version 6.x is no longer supported from elastalert2 2.4.0, and the guidance is to use the praecoapp/elastalert-server image tagged 20220109 with elastalert2 installed before 2.4.0. Version 7.x is supported. Version 8.x is supported with Praeco 1.8.11 or later, and elastalert-server is compatible with it. Version 9.x is supported with Praeco 1.8.21 or later, with elastalert-server compatible as well. And a version that is not the latest is not supported.

The same FAQ is careful about which server to use. The bitsensor/elastalert image does not implement the features Praeco requires, and neither does karql/elastalert2-server, and in both cases the answer is to use praecoapp/elastalert-server. The original yelp/elastalert is no longer supported because maintenance was discontinued, with the specific problems being that it is not compatible with Python 3.12 or later, that PagerTree, Stomp and Zabbix notifications do not work because of a bug, and that Kibana Discover only guarantees operation up to Kibana 7.3.

The GUI has limits of its own. The FAQ says it is not possible to set Percentage Match on the screen, not possible to set Spike Aggregation on the screen, and not possible to set a custom timestamp format there either. The practical implication is that some ElastAlert 2 options still have to be written into the YAML by hand, and Praeco is the friendly way to get most of the way there rather than the whole way.

The alternative approach is the one ElastAlert users had before: write the rule in YAML and run ElastAlert directly. Praeco earns its place when the people writing alerts are not the people who know the rule format, or when you want to see the matching documents before the alert is live.

Editorial conclusion

praeco suits an operations team that runs ElastAlert against Elasticsearch and has more than one person who needs to write a rule without learning the YAML, and it suits anyone who wants to see the matching documents in a chart before committing an alert to production. It does not suit you if you are running ElastAlert 2 directly and have one rule to maintain, and it does not suit a team that needs a support commitment, because the README states plainly that the project is looking for a new maintainer and that there is no obligation to fix bugs, respond to requests or add features. Check three things before you adopt it: which Elasticsearch version you run, since support is version specific, whether the elastalert-server image from the praecoapp organisation is acceptable to you, since the README rules out the bitsensor and karql alternatives, and what you plan to do about maintenance. The last push to the repository was on 2026-10-20 and the newest release is 1.8.27 from 2026-10-07.

Frequently asked questions

Official sources

1. Issues
2. johnsusek/praeco on GitHub
3. License: GPL-3.0
4. README
5. Releases