AlertLoop
A self-hosted event and notification center for software teams.
Collect important application events, route notifications and keep delivery failures visible and recoverable, on your own infrastructure, with no third-party service in the path.
# POST an event to a self-hosted AlertLoop
curl -X POST http://localhost:8080/v1/events \
-H "X-API-Key: change-me-admin" \
-H "Content-Type: application/json" \
-d '{
"type": "incident",
"severity": "critical",
"source": "feeds_worker",
"message": "Feed processing failed",
"dedupe_key": "feeds:developer:15:flats"
}'
# Stored, deduplicated, queued for every
# configured channel — with retries.
The problem
Important events should not disappear in logs
Applications generate incidents, business events and operational warnings. Without a shared delivery pipeline, these events remain scattered across logs, emails and one-off integrations.
01
Nobody sees it
A failed nightly job writes one line to a log file. The line is correct, structured and read by no one until a customer complains.
02
Every service invents delivery
Each application grows its own SMTP block, its own webhook sender and its own idea of what a retry means. None of them agree.
03
Failures fail silently
A notification that never arrived leaves no trace. There is no attempt history, no dead letter, and nothing to replay once the channel is back.
Product overview
One place events arrive, and one pipeline that delivers them
Applications POST events to a single API. AlertLoop stores them, deduplicates them, queues delivery to every configured channel, retries what fails and keeps the failures where you can find and replay them. It ships as one Go binary with an embedded React admin console and Swagger UI, backed by SQLite for a demo or PostgreSQL in production.
Architecture
The delivery pipeline
The happy path is deliberately short. Everything interesting happens in the failure path underneath it.
Source
ApplicationIngest
AlertLoop APIPersist
Event storageQueue
Delivery queueSend
WorkersChannels
Email / Webhook / TelegramWhen a delivery fails
Event state (new, acknowledged, resolved, muted, escalated) and delivery state are kept apart on purpose. An incident can be resolved while its email notification is still failing. Those are two different facts, and collapsing them into one status field is how delivery problems become invisible.
Core capabilities
What the Community edition actually does
Everything listed here is in the released v0.1.0 binary. Nothing on this list is planned, partial or aspirational.
Event ingestion
An Events API with API-key auth and scopes (ingest, read, full), documented by a live OpenAPI contract and Swagger UI.
Three event families
incident, business_event and audit: an operational failure and a signed contract are not the same thing and should not share a shape.
Event lifecycle
Events move through new, acknowledged, resolved, muted and escalated, with a manual escalate action.
Idempotent ingestion
A dedupe_key makes repeated sends safe. A worker that retries its own failure does not produce five identical incidents.
Notification routing
Every event is delivered to every configured channel. Per-event routing rules are a paid capability and are not in Community.
Email delivery
SMTP with STARTTLS or implicit TLS. AlertLoop refuses to send in plaintext when TLS was requested and is unavailable.
Webhook delivery
Outbound webhooks are HMAC-signed, so the receiving system can verify that the payload came from your AlertLoop.
Telegram delivery
A fully supported channel with the same retry and dead-letter path as email and webhooks, for teams that live in Telegram.
Retries, dead letter, replay
A delivery worker with exponential backoff, a dead-letter queue for exhausted jobs and a replay endpoint to send them again.
Delivery visibility
Full delivery-attempt history, stored separately from event state, plus cursor-paginated list endpoints for reading it.
Admin console
A React console (Overview, Events, Event detail, Deliveries with dead-letter replay) embedded in the binary and served at /admin, protected by a single admin token; Community has no user accounts.
Self-hosted deployment
One CGO-free binary (server, worker or all mode) with Docker Compose and systemd units. Structured logs, built-in rate limiting and 30-day retention.
Editions
One edition exists. Two are planned.
AlertLoop starts self-hosted. Cloud SaaS is deferred on purpose until the core product and its positioning are validated, and until asking teams to send incidents to a service run by one person is a reasonable thing to ask.
Community
The self-hosted core product for developers and small teams: Events API, Swagger/OpenAPI, admin console, Email / Webhook / Telegram delivery, retries, dead letter and replay, SQLite and PostgreSQL.
Free · Self-hosted · AGPL-3.0-only
Pro Self-hosted
Planned. Not built. May include multi-project support, RBAC, advanced routing rules, escalation policies and on-call schedules, SDKs for PHP, Go and JavaScript, a WhatsApp adapter, Telegram proxy/fallback and longer configurable retention.
Commercial licence · pricing not set
Enterprise
Planned. Not built. May include an on-prem commercial licence, SSO, audit log search and export, HA deployment, a Helm chart, custom adapters and support.
Commercial licence · pricing not set
My role
What I own on this project
Product definition, architecture, implementation direction, technical review and release management.
AI agents write a large share of the code. I decide what the product is, how the system is structured, what a correct failure path looks like and what is allowed into a release.
Current status
Current state of the product
Community edition v0.1.0 is released and runs: prebuilt binaries, Docker Compose, SQLite and PostgreSQL. Product documentation is in development. The commercial Pro and Enterprise editions are planned, not built.
Roadmap
What shipped, what I'm doing now, what comes next
Phases marked as shipped are in the released binary. The rest are intentions, and I mark them as such.
-
Product definition
Product brief, business model, licensing model, technical architecture, API draft and deployment model, all decided before the first line of Go.
-
Community backend MVP
Events API with API-key auth, SQLite and PostgreSQL, dedupe-key idempotency, event lifecycle actions, Email, HMAC-signed Webhook and Telegram channels, retry worker, dead-letter replay, OpenAPI/Swagger, admin console, Docker Compose demo and prebuilt binary releases.
-
Production self-hosted
PostgreSQL migrations, config-file support, split server/worker modes, improved retry and backoff, dead-letter view and 30-day retention cleanup are in v0.1.0. Remaining work: hardening against real production use, health and readiness coverage, and a dedicated documentation site.
-
Pro edition
Multi-project support, RBAC, SDKs for PHP, Go and JavaScript/Node.js, a WhatsApp adapter, Telegram proxy/fallback, advanced routing rules, escalation policies and on-call schedules, configurable retention, audit-log search and export.
-
Enterprise
Commercial licence tooling, SSO, audit log, HA deployment documentation, a Helm chart and custom adapters.
Related notes
The decisions behind AlertLoop
Written while the work was still fresh, including the parts that did not go to plan.
Run it yourself, or tell me where it breaks.
AlertLoop is free, self-hosted and open source. If you deploy it and something is wrong (a channel that fails, a failure path that isn't recoverable, a missing capability), that is exactly the feedback the product needs right now.