LoggiFly is a small watcher that reads the logs of your Docker containers and tells you when something in them matters. You give it a list of containers and a list of keywords or regular expressions, and every log line that matches is turned into a notification with the surrounding context attached. It is built for the alerts you actually want from a homelab: a failed login on Vaultwarden, an error that precedes a crash, a download that finished on Audiobookshelf – patterns you know are meaningful but that no metrics dashboard will ever show you.

How it works

LoggiFly runs as a container with the Docker socket mounted read-only-ish, lists the containers you name in its config, and follows their log streams. Matching is on plain text or on regular expressions, and patterns can span multiple log lines, which is what catches stack traces and multi-line error dumps that a per-line grep would miss. Each match produces a notification whose body can be shaped with templates and filters, so the message carries the part of the log line you care about instead of the whole raw entry. A log file can be attached to the notification for the cases where you want the context to travel with the alert.

Notifications through ntfy and Apprise

Delivery goes two ways: directly to an ntfy topic, or through Apprise, which reaches a long list of services including Slack, Discord, Telegram and generic webhooks. That means one config file can route a security match to a phone and a routine event to a chat channel, without a messaging gateway of its own.

Acting on a match

A match can do more than notify. LoggiFly can restart or stop the container that produced the line, which is how it handles the two classic failure shapes: a container stuck in a crash loop that needs a stop rather than another restart, and a service that recovers cleanly when it is kicked. Because the action is tied to a pattern you wrote, the trigger stays visible in configuration rather than hiding inside a restart policy.

Configuration and reloading

Everything lives in a single config.yaml: containers to watch, patterns, notification targets, message templates and per-container actions. LoggiFly watches that file and reloads itself when it changes, so tuning a pattern does not mean recreating the container. The same instance can attach to several Docker hosts over TCP, which is how a central LoggiFly watches containers spread across more than one machine.

Where it fits

LoggiFly is a log-pattern alerter, not a log store or a dashboard: it keeps no history, so it pairs with whatever already collects your logs rather than replacing it. It runs on Docker, Docker Swarm and Podman. For the pieces around it, Uptime Kuma covers availability checks and status pages, Prometheus covers metrics and alert rules, and Grafana covers the dashboards over both – LoggiFly covers the one signal none of them read, which is what your application actually printed.

Alternatives

• Uptime Kuma – uptime monitoring and status pages
• Prometheus – metrics collection and alerting rules
• Grafana – dashboards and alerting over metrics and log stores