Alerta's server, its eight entry point plugins, and the guardian URL still in its metadata

Two distributions and eight plugins declared as entry points

Alerta installs as two distributions, not one: `pip install alerta-server alerta` pulls the WSGI server and the command line client. The server packaging reads its version from a `VERSION` file at the repository root and its long description from `README.md`, which means this same page is what a `pip` user ends up reading on a package index. Plugins are not a directory you drop files into; they are entry points named in the packaging, and eight ship by default: `remote_ip` to take the address from the connection, `reject` as a reject policy, `heartbeat` to receive heartbeats, `blackout` to suppress alerts inside a window, `acked_by` to record who acknowledged, `escalate` to change severity, `forwarder` to pass alerts onward, and `timeout` as a timeout policy. The one console script it registers is `alertad`, which is the command behind `alertad run`. The root of the tree also carries `MANIFEST.in`, a `NOTICE` file, a `wsgi.py` module, and both a `.env` and a `.flaskenv`, which is an unusual pair for a server whose documented configuration path is a file under `/etc`.

Postgres or MongoDB, with loose floors beside a pinned file

Release 9 requires Python 3.9 or higher, and the only mandatory dependency is a database: Postgres 13 or newer, or MongoDB 6.0 or newer, with everything else optional. The two backends arrive as extras, `mongodb` for pymongo and `postgres` for psycopg2, so the driver you get depends on which extra you name. The declared floors are loose: Flask is asked for at 2.0.1 or higher, PyJWT at 2.0.0, sentry-sdk at 0.10.2, while bcrypt, blinker, cryptography, defusedxml, pyparsing, python-dateutil, pytz, PyYAML, requests, requests-hawk and StrEnum carry no floor at all. The pinned file says something different, with Flask at 3.1.3, werkzeug at 3.1.7, Flask-Cors at 6.0.2, pymongo at 4.16.0, psycopg2 at 2.9.11 and bcrypt at 5.0.0. Sitting in the same list are defusedxml, cryptography, bcrypt, PyJWT, and the Hawk pair mohawk and requests-hawk, none of which the page explains. There are three dependency files at the root rather than one, `requirements.txt`, `requirements-ci.txt`, and `requirements-dev.txt`, so the library floor, the continuous integration set, and the development set are maintained apart. A directory named `pref-db-rawdata-history` also sits at the top level, with nothing in the visible files saying what reads it.

The compose file creates a monitoring database with the password postgres

The shipped compose file runs two services, `ghcr.io/alerta/alerta-api` and `postgres`, with the API on port 8080 and the database port 5432 published to a random host port. The credentials are written into the file as `POSTGRES_USER: postgres` and `POSTGRES_PASSWORD: postgres`, and the API's `DATABASE_URL` embeds the same pair, so a development default travels with the file instead of arriving per deployment. Both services carry `restart: always`, and the file opens with a `version: '3.1'` key that current Compose ignores. The debug line is commented out and its own comment says to remove the line to turn DEBUG off, which means the value depends on whether you uncomment it or delete it, and neither state is stated plainly. The database in this file is `monitoring`, while the development instructions elsewhere on the page point at a database called `alerta5`.

The package URL still names the guardian organization

The packaging metadata carries `url='https://github.com/guardian/alerta'` while the repository itself is `alerta/alerta`, so the link a package index shows for the server points at an older organization path. The license block at the bottom of this page reads Copyright 2012-2023, and the releases kept going past that year: v9.0.3 in April 2024, v9.0.4 in September 2024, and v9.1.0 in March 2026. The last recorded push is 2026-06-19, which is after that tag and carries no version number of its own. The de-coupled design shows up in the list of repositories rather than in the code: the web console is built in `alerta-webui`, the Heroku, CloudFormation and Google Cloud recipes live in three more repositories, and none of them is in this tree. What is here is the server, the client, the plugin entry points, and the tests.

The console is a static bundle served by python3 -m http.server

The web console is not packaged with the server. The instructions download a tarball from the console repository's releases, unpack it, change into the `dist` directory, and serve it with `python3 -m http.server 8000`, then browse to `http://localhost:8000`. Python's built-in static server is the entire deployment story for the console, which puts the interface on port 8000 and the API on a different port: 8080 in the compose file, and 5000 when `flask run` starts in development mode. That split is the reason the troubleshooting notes send you to the browser's developer console for JavaScript logging, network problems, and API error responses, since the page you are debugging is served from one origin and talks to another. Nothing in these instructions sets a base URL for the console or a CORS origin on the API side. Embedding is treated as an example rather than a feature list, with `examples/oembed.html`, a Grafana flavoured `examples/oembed-for-grafana.html`, plus `examples/plugins/` and `examples/backends/` directories, and further reading pushed to `docs.alerta.io`.

Debug logging writes to a literal $HOME path

The documented way to see what the server is doing is a configuration block, and one line of it is a path with a shell variable still sitting in it:

DEBUG=True

LOG_HANDLERS = ['console','file']
LOG_FORMAT = 'verbose'
LOG_FILE = '$HOME/alertad.log'

With the file handler switched on, whether `$HOME` is expanded or treated as a literal directory name depends on the configuration loader, and the page does not say which. The development recipe in the same file exports a Sentry DSN containing a fixed project key, so anyone who copies it reports their local errors into somebody else's Sentry project. That recipe also sets `DATABASE_URL=postgres://localhost:5432/alerta5`, and the name `alerta5` appears nowhere else in this repository, while the compose file creates `monitoring`. Configuration itself is pointed at `/etc/alertad.conf`, or at whatever path the `ALERTA_SVR_CONF_FILE` variable names. Development mode is a plain Flask app in the same shape: `FLASK_APP=alerta` with `FLASK_DEBUG=1`, then `pip install -e .` and `flask run`, while the Postgres variant adds the database URL, the Sentry DSN, the postgres extra, and `flask run --debugger --port 8080 --with-threads --reload`.

Five bandit checks switched off, and two test paths that disagree

The scanner configuration at the repository root switches off five checks and gives one line of reasoning for each: assert usage outside tests, hardcoded password strings, hardcoded password function arguments, requests without a timeout on calls to external identity providers, and hardcoded SQL expressions, the last justified by psycopg2 parameterization. Two of those deserve a second look in a server whose compose file ships default credentials, and the timeout exemption applies to every outbound identity call. The tests are split along the same seam. `TOXENV=ALL make test` wants a local Postgres and a local MongoDB running at once, `TOXENV=postgres` and `TOXENV=mongodb` narrow it to one, and the two single-test examples point at different files for what looks like the same suite: `tests/test_search.py::QueryParserTestCase::test_boolean_operators` on the MongoDB side, `tests/test_queryparser.py::PostgresQueryTestCase::test_boolean_operators` on the Postgres side.

Editorial conclusion

Alerta fits a team that wants one API in front of many monitoring sources, accepts picking Postgres or MongoDB as a deployment decision, and is willing to run the web console from its own static build. Read three things first: the compose file ships the database password as the literal word postgres and publishes the database port, the default configuration in that same file decides whether debug output exists, and the packaging metadata links to an older organization path, so a package index entry will point you at the wrong repository. If you plan to run it in production, set the secret properly, keep debug off, and check the five bandit exemptions before you trust the security posture. On the tests, expect to bring up both databases for a full run.

Frequently asked questions

Official sources

1. alerta/alerta on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases