LoggiFly

Container log monitoring, honestly reviewed. No marketing fluff, just what you get when you self-host it.

TL;DR

• What it is: MIT-licensed, Python-written tool that watches Docker container logs for keywords and regex patterns, then fires notifications to ntfy, Slack, Discord, Telegram, and 100+ other services via Apprise [1][2].
• Who it’s for: Self-hosters and homelab operators running Docker stacks who want to catch failed logins, crashes, and critical errors in real time — without spinning up Prometheus, Loki, or a full observability stack [1].
• Cost savings: Free versus commercial log alerting services that start around $7–25/month and scale painfully with log volume. LoggiFly runs on the same server as your containers at no additional cost [1][2].
• Key strength: Genuinely targeted. You define the exact keywords or patterns that matter per container. Nothing else pings you. Reviewers consistently call it “simple by design” and mean it as a compliment [1].
• Key weakness: No log storage, no dashboards, no metrics. This is an alerting sidecar, not an observability platform. If you want to query logs historically or visualize trends, LoggiFly won’t help you [1][2].

---

What is LoggiFly

LoggiFly is a lightweight Docker container log monitor. You give it a YAML config that says: “watch these containers, match these patterns, send these alerts.” That’s the entire product. It hooks into the Docker socket, reads the live output of running containers, and triggers notifications when a log line matches what you defined [2].

The GitHub description is refreshingly accurate: “Get Alerts from your Docker Container Logs” [README]. There’s no mission statement about “unified observability” or “intelligent monitoring” — it does one thing and the README tells you what it is immediately.

The use cases the README calls out are concrete and recognizable to anyone running a self-hosted stack: catching failed login attempts in Vaultwarden, debugging crashes with log context attached, restarting containers that hit specific error states, and tracking custom app behaviors like when a user downloads an audiobook from your Audiobookshelf instance [README]. These aren’t invented scenarios. They’re the exact events that keep self-hosters up at night.

As of this review, LoggiFly sits at roughly 1,700 GitHub stars [3] — notable for a tool with such a narrow scope. It’s MIT-licensed, maintained by a solo developer (clemcer), and has no commercial version, no cloud offering, no paid tier. It’s just software you run [README][3].

---

Why people choose it

Both XDA reviews that covered LoggiFly land on the same reason people install it: it fills the gap between “manually tail logs in Portainer” and “set up a full Prometheus/Loki/Grafana stack” — a gap that exists for most homelab operators and turns out to be exactly where the common use cases live [1][2].

Jeff Butts at XDA puts it well: “Many of us in the self-hosting community don’t need the complexity of Prometheus, Loki, or Elasticsearch just to get pinged about a failed database migration. LoggiFly gives you lightweight, targeted observability with minimal setup.” [1] That framing is accurate. The full observability stack is genuinely overkill for a home server running ten containers and a single operator who just wants to know when something breaks.

The notification flexibility is repeatedly cited as a differentiator. Rather than locking you into one channel, LoggiFly routes alerts through ntfy (for simple self-hosted push) or Apprise — which covers Discord, Telegram, Slack, email, Matrix, Gotify, and over 100 other services [1][2][README]. Dhruv Bhutani at XDA describes a particularly useful pattern: routing critical errors to Discord DMs while warnings go to a shared Slack channel [2]. That kind of per-trigger routing normally requires either a dedicated alerting tool or a lot of scripting.

The template support is the other thing reviewers mention. Instead of a generic “keyword matched in container X” message, you can receive something like: ”🚨 [nextcloud] encountered ERROR: failed login from 192.168.1.12” — because you wrote the template that extracts and formats the relevant fields [1]. That context means you know what happened before you open a dashboard.

Self-Host Weekly featured LoggiFly in its May 2025 content spotlight, describing it as “a self-hosted platform for container log monitoring and alerts” and calling out the ease of triggering notifications for security breaches, container errors, and custom app actions [5]. The fact that it surfaced there — a newsletter that covers hundreds of self-hosted tools — suggests it reached a meaningful audience of actual home server operators, not just GitHub trophy hunters.

---

Features

Based on the README, website, and third-party coverage:

Log detection:

• Plain text keyword matching [README][1]
• Regex pattern support — lets you match structured log formats, IPs, error codes, UUIDs [README][1]
• Multi-line log detection for stack traces or events that span multiple lines [README][3]

Notifications:

• Direct ntfy integration (ntfy is itself a self-hosted push notification server) [README][2]
• Apprise integration covering Discord, Telegram, Slack, email, Gotify, Matrix, and 100+ other services [README][1][2]
• Template variables in notification titles and bodies — format your own messages with context from the matched log line [README][1]
• Per-container topic/tags/priority settings for ntfy [3]
• Log file attachments — include the surrounding log context with the notification, not just the matched line [README][2]

Actions on match:

• Restart the container when a specific pattern is matched [README][2]
• Stop the container to prevent restart loops [README]
• OliveTin integration — trigger custom OliveTin actions on match [website]

Container monitoring:

• Docker socket integration for live log tailing [2]
• Remote Docker hosts — connect to multiple Docker daemons across machines [README][website]
• Docker Swarm and Podman support [README]
• Container event monitoring — crashes, restarts, starts, stops [website]

Configuration:

• YAML-based config with automatic hot reload on save — no container restart required [README][2][3]
• Docker labels support — configure monitoring in the compose labels of the container you want to watch, rather than a separate file [website]
• Environment variable configuration as an alternative to YAML [website]
• Container grouping by tags, name patterns, or labels [1]

What it doesn’t do:

• No log storage. Nothing is persisted. If you want to query logs from last Tuesday, LoggiFly won’t help [2].
• No dashboard or visualization [1].
• No metrics collection (CPU, memory, request rates — none of that) [1].
• No anomaly detection. Matches are rules you wrote, not patterns it learned.

---

Pricing: self-hosted math vs. commercial alternatives

LoggiFly has no pricing tier because it has no commercial offering. It’s MIT software you deploy yourself [README][3].

The relevant cost comparison is against commercial log alerting services that do what LoggiFly does, or adjacent tools that are often the other option people evaluate:

Commercial log management (typical pricing):

• Papertrail (by SolarWinds): free tier covers 50MB/day and 7-day retention. Paid plans start at roughly $7/month for 1GB/day. Scales quickly past $100/month for active Docker stacks with verbose logs.
• Better Stack Logtail: free tier at 1GB/month with 3-day retention. Paid plans start around $25/month for more volume and longer retention.
• Datadog Log Management: complex per-GB ingested pricing, typically $0.10/GB on top of host monitoring fees. For a small homelab this might be $20–30/month; for a production stack it can reach hundreds.

Self-hosted stack alternatives (free software, not free to run):

• Loki + Grafana + Promtail: zero software cost, but you’re running multiple additional containers on the same or a separate host, writing PromQL/LogQL to build dashboards, and maintaining the stack. Realistic setup time for someone new to it: a weekend. Ongoing maintenance: real.
• ntfy alone: free if self-hosted, but you’re writing your own log-watching scripts and wiring them to ntfy. LoggiFly is what that script becomes when you want it to be reliable.

LoggiFly on your existing server:

• Software: $0 [README][3]
• Additional VPS required: none, it runs alongside your stack
• Monthly cost: whatever fraction of your existing server it consumes — roughly zero for a small container

For a non-technical founder running a self-hosted stack on a $6–12/month VPS, the math isn’t complicated. If you’re paying $25/month for Logtail to tell you when your container crashes, you can stop paying that. If you’ve been manually checking logs in Portainer and missing things, LoggiFly costs nothing to install [1][2].

The caveat: LoggiFly doesn’t replace Logtail or Papertrail for log search and retention. It replaces the alerting and notification function only. If you need historical log querying, you still need something else.

---

Deployment reality check

LoggiFly deploys as a Docker container alongside your existing stack. The README ships a docker-compose snippet and the setup is documented [README][getting-started page]. The XDA reviews describe it as straightforward for anyone already comfortable with Docker Compose [1][2].

What you actually need:

• A Docker host (the same machine running your other containers works fine)
• Docker socket access — LoggiFly mounts /var/run/docker.sock to read container logs
• A notification target: either a running ntfy instance, or an Apprise-compatible service like Discord, Telegram, or Slack
• A config.yaml defining which containers to watch and which patterns to match

What the config looks like in practice: You define containers (by name, tag, or label) and for each one, a list of triggers. A trigger is a keyword or regex and an action (notify, restart, stop, or OliveTin call). Templates let you control what the notification says. Config changes are picked up without restarting LoggiFly [README][2][3].

What can go sideways:

• The Docker socket mount is a security consideration. Giving a container access to /var/run/docker.sock means it can control other containers. This is common in homelab tools (Portainer, Dozzle, Watchtower all do it) but worth noting if you’re security-conscious [2].
• Regex can match too broadly if you’re not careful — a pattern matching “error” in every container will create alert fatigue quickly. You’ll want to spend time calibrating rules [1].
• There’s no web UI. Configuration is YAML-only [README]. If you’re comfortable with Docker Compose you’re comfortable with this; if YAML config is unfamiliar territory, budget extra setup time.
• Single developer project. There’s no company, no SLA, no commercial support [3]. The GitHub issues page is where bugs go. For a homelab alerting sidecar this is fine; for production critical infrastructure it’s worth noting.

Realistic setup time for someone already running Docker Compose stacks: 15–30 minutes to a working alert. Most of that time is writing your first set of trigger rules and testing that they fire.

---

Pros and cons

Pros

• Actually lightweight. The XDA review explicitly contrasts it with Prometheus/Loki/Elasticsearch and calls it “simple by design” — that simplicity is intentional and well-executed [1]. It doesn’t accumulate features trying to become a full observability platform.
• MIT license, free forever. No commercial tier, no feature gating, no vendor lock-in [README][3]. The software you deploy today will still work in three years without a license renewal.
• Apprise integration gives you 100+ notification destinations. You almost certainly already use at least one service Apprise supports [README][1][2].
• Per-container granularity. Different containers can have different keywords, templates, notification channels, and ntfy priorities [1][3]. One tool, configured to match your actual ops context.
• Hot reload on config change. You don’t restart the container to update rules. Save the file, LoggiFly picks it up [README][2][3].
• Log attachments with notifications. The matched alert arrives with surrounding log context already attached — you’re not opening Portainer to figure out what happened [README][2].
• Remote host support. If you’re running Docker on multiple machines, one LoggiFly instance can watch all of them [README][website].
• Container action triggers. Auto-restart or auto-stop on specific patterns. Useful for containers that enter crash loops on specific errors [README][2].

Cons

• No log storage or history. This is the biggest genuine limitation. LoggiFly reacts to logs in real time but stores nothing. If you miss an alert or want to review what happened an hour ago, you need another tool [1][2].
• No dashboard or visualization. No UI to review past alerts, no trend charts, no log search [1]. It’s alerts in, notifications out.
• YAML-only configuration. There’s no web interface to configure rules. Accessible for anyone who writes Docker Compose; a barrier for people who’ve never edited YAML [README].
• Solo maintainer project. 1,700 stars is solid traction but the entire project depends on one developer [3]. Community is small — AlternativeTo shows no reviews as of writing [3].
• Docker socket dependency. The security tradeoff of mounting the Docker socket is real and worth understanding before deployment [2].
• Regex calibration takes time. Getting rules tight enough to avoid noise without missing real events requires iteration. It’s not “install and done” — it’s “install, watch for a week, tune” [1].
• No anomaly detection. You get what you define. If there’s a new error class you haven’t written a rule for, you won’t be alerted. This is a deliberate design choice but means it won’t catch the unknown unknowns.

---

Who should use this / who shouldn’t

Use LoggiFly if:

• You run a homelab or personal server with Docker containers and you want to know immediately when something fails, not when you happen to check Portainer next.
• You’re already using ntfy, Discord, Telegram, or Slack for other notifications — adding LoggiFly alerts to an existing channel is trivially easy via Apprise.
• You want targeted, low-noise alerts without standing up Grafana, Loki, and Promtail.
• You care about specific events per container: failed logins in Vaultwarden, specific error codes from your database, download completions from a media server.
• You’re a self-hosting beginner who finds full monitoring stacks intimidating and just wants to get a ping when something breaks [1].

Skip it if:

• You need to query historical logs. LoggiFly stores nothing — pair it with Loki or Papertrail if retention matters.
• You want dashboards and visualization. Use Grafana.
• You’re running this in a production environment with compliance requirements. A solo-maintained MIT tool without a commercial support option is the wrong fit.
• Your containers are already instrumented with OpenTelemetry and you want correlated traces, metrics, and logs. HyperDX, Signoz, or a full observability platform is the right answer [4].

It’s fine if you combine it with a log storage tool. LoggiFly handles the “alert me now” function; a separate tool handles “let me search last week’s logs.” They don’t conflict.

---

Alternatives worth considering

• Dozzle — Docker log viewer with a real-time web UI. Great for reading logs, no alerting. The complementary tool, not a replacement.
• Loki + Grafana + Promtail — the full open-source log stack. Stores logs, enables querying, visualizes trends. Much heavier to operate. Right answer for teams; overkill for one person.
• ntfy alone — if you already have ntfy and just need to send yourself custom notifications, you can write a shell script that watches docker logs -f and pipes to ntfy. LoggiFly is what that script becomes once you need regex, multiple containers, templates, and restart actions.
• HyperDX — open-source alternative to Datadog that unifies logs, traces, metrics, and session replays. TypeScript-based, ClickHouse-backed, 9,400+ stars [4]. Right for engineering teams who want full observability; complete overkill as a Vaultwarden login monitor.
• Netdata — real-time performance monitoring with alerting. Covers metrics and infrastructure health. Doesn’t read application log content.
• Uptime Kuma — monitors whether services are up and responding. Different problem: availability vs. log content.
• Zabbix / Nagios — enterprise-class monitoring platforms. Powerful, complex, require dedicated setup and maintenance. Not the right tool unless you’re already running them [3].
• Datadog — covers everything LoggiFly does and infinitely more. Also costs infinitely more. Pricing based on host count and log volume reaches $100+/month for a modest stack.

For someone whose specific need is “alert me when my Docker containers log something important,” the realistic shortlist is LoggiFly vs. writing it yourself vs. paying Papertrail $7/month. LoggiFly wins that comparison on every axis except the YAML config learning curve.

---

Bottom line

LoggiFly is a single-purpose tool that does exactly what it claims and nothing more. It watches your Docker container logs, matches the patterns you define, and fires a notification wherever you want it. There’s no commercial agenda, no feature creep into dashboards or metrics, no free-tier-with-upsell. It’s a well-built alerting sidecar for people running Docker stacks who want to be the first to know when something goes wrong, not the last.

The trade-off is also clear: it stores nothing, visualizes nothing, and detects nothing you didn’t explicitly define. If you need log history or don’t yet know what to alert on, you need something else alongside it. But for the targeted use case — getting a Discord ping when Vaultwarden logs a failed login, or an ntfy notification when a container hits a fatal error at 3am — it’s the lowest-friction, highest-precision option in the self-hosted category. Zero software cost, 15 minutes to install, and it runs quietly forever on the same server you already have.

---

Sources

1. Jeff Butts, XDA Developers — “This advanced notification tool can read the logs of your self-hosted services for custom alerts” (Jun 13, 2025). https://www.xda-developers.com/advanced-notification-tool-read-logs-self-hosted-services-custom-alerts/
2. Dhruv Bhutani, XDA Developers — “This self-hosted app lets you get real time alerts from Docker container logs” (Oct 15, 2025). https://www.xda-developers.com/app-lets-you-get-real-time-alerts-docker-container-logs/
3. AlternativeTo — “Loggifly: Monitor Docker logs and send notifications”. https://alternativeto.net/software/loggifly/about/
4. AlternativeTo — “HyperDX: An open source observability platform”. https://alternativeto.net/software/hyperdx/about/
5. Ethan Sholly, selfh.st — “Self-Host Weekly (16 May 2025)”. https://selfh.st/weekly/2025-05-16/

Primary sources:

• GitHub repository and README: https://github.com/clemcer/loggifly (~1,700 stars, MIT license)
• Official documentation: https://clemcer.github.io/LoggiFly
• Getting Started guide: https://clemcer.github.io/loggifly/guide/getting-started
• Configuration reference: https://clemcer.github.io/loggifly/guide/config-structure.html