Logtide: 2 Months After Launch (The Real Numbers)

Source: Dev.to

Two months ago, I launched Logtide (then called LogWard) – an open‑source, privacy‑first alternative to Datadog and Splunk.

📊 The Numbers (Completely Honest)

GitHub

Usage

✅ What Actually Worked

1. The Right Marketing Channels

Winner: virtualizationhowto.com – a tech blogger discovered Logtide and wrote about it.

• Result
  • 120+ GitHub stars from that single post
  • Traffic spike: 2,500 visitors in 24 h
  • 80+ new self‑hosted deployments

Lesson: One good write‑up from a respected voice > 10 posts on social media.

Runner‑up: Reddit + Dev.to – posts on r/selfhosted and Dev.to brought consistent traffic.

• Why it worked
  • Self‑hosters care about privacy (GDPR angle)
  • Docker‑Compose deployment (5 min from clone to running)
  • “No vendor lock‑in” message resonated

2. The Features People Actually Use

Surprise: SIEM usage is way higher than expected.

Why? Users want to detect threats, not just see logs.

Most popular Sigma rules aren’t even security‑focused:

• “Payment failed” alerts
• “API 500 error” spikes
• “Database timeout” patterns

Lesson: Security features sell, but business monitoring is what people actually use.

3. Technical Decisions That Paid Off

TimescaleDB was the right choice.

Largest deployment stats

• 500 k logs/day
• 30‑day retention
• DB size: 15 GB (compressed)
• Query performance: sub‑100 ms

Lesson: “Good enough” performance + operational simplicity > maximum speed.

4. Community Requests That Made Sense

Issue #68 – Substring Search

• Request: “I can’t find bluez in spa.bluez5.native using full‑text search.”
• Initial thought: “Full‑text search is fine, use wildcards.”
• Reality: 40 % of searches now use substring mode.

Why?

• UUIDs in logs (partial search)
• File paths (e.g., /app/services/auth)
• Service names with dots

Lesson: Users know their workflows better than you do. Listen to GitHub issues.

❌ What Didn’t Work

1. The Rebrand (Forced, Not Chosen)

Impact

• Lost all SEO momentum (Google indexed “LogWard”)
• Broke old links/bookmarks
• Confused early users (“wait, what’s Logtide?”)

Cost: ~40 h renaming docs, SDKs, Docker images, etc.

Lesson: Check trademarks BEFORE naming anything. Period.

Silver lining: “Logtide” sounds cooler than “LogWard”.

2. Features Nobody Asked For

OpenTelemetry metrics (not implemented yet)

• Plan: Support OTLP metrics (CPU, memory, …)
• Reality: Only 2 users asked for it.

Why? Most users already use Prometheus for metrics.

Decision: Postponed indefinitely. Focus on logs + traces.

Lesson: Build what users request, not what you think they need.

3. Architectural Regrets

Redis might be unnecessary.

• Current stack

  • PostgreSQL + TimescaleDB (logs storage)
  • Redis (background job queue with BullMQ)

• Problem: Redis adds operational complexity for self‑hosters.

• Alternative being explored

  • PostgreSQL SKIP LOCKED for job queue (proved in “I Replaced Redis with PostgreSQL” article)

• Next version (0.5.0): May remove Redis entirely.

Lesson: Every dependency is a liability. Question everything.

😮 Unexpected Learnings

1. Self‑Hosted Dominates

• Expected: 50/50 cloud vs. self‑hosted
• Reality: 90 % self‑hosted

Why?

• Privacy concerns (GDPR)
• Data‑residency requirements
• Control over infrastructure
• Distrust of SaaS logging platforms

Roadmap impact

• Prioritize Docker‑Compose improvements over cloud features
• Better self‑hosting docs
• Add a Kubernetes Helm chart

Lesson: Know your actual users, not your imagined ones.

2. Sigma Rules Are a Differentiator

• Expectation: “Nice‑to‑have security feature”
• Reality: “Primary reason for choosing Logtide”

User feedback

• “Finally, security detection without Splunk costs.”
• “Sigma rules work out of the box.”
• “MITRE ATT&CK mapping is amazing.”

Most requested

• More pre‑built Sigma rules
• SigmaHQ integration (auto‑import rules)
• Custom rule‑editor UI

Lesson: Find your unique angle. For Logtide it’s **