DEV Community: IndieSquadTools

Centralizing logs across servers or background workers often introduces unnecessary operational overhead

IndieSquadTools — Sun, 02 Aug 2026 07:56:17 +0000

Centralizing logs across servers or background workers often introduces unnecessary operational overhead. Running dedicated search clusters like Elasticsearch requires significant memory and maintenance, while SaaS logging providers charge monthly rates that scale directly with data volume. For smaller deployments, these options are often disproportionate to the actual problem: finding recent error messages and getting notified when something breaks.

LogFloor is a lightweight, self-hosted log search and alerting tool. Purchased as source code for a $49 one-time fee, it runs entirely on your own infrastructure using SQLite for storage, eliminating managed database costs and recurring subscription fees.

Technical Overview

LogFloor operates around three core functions:

HTTP Ingestion: A single HTTP ingest endpoint accepts incoming log payloads from your applications or scripts.
Search: An interface allows querying stored logs using keyword filtering and specific time ranges.
Alerting: Threshold-based alert rules monitor log occurrences and fire an HTTP request to a user-configured webhook URL when triggered.

Because the underlying datastore is SQLite, all log data resides in a local database file, simplifying backup and operational requirements to standard file-system management.

Example Usage

To send logs to LogFloor, send an HTTP POST request to the ingestion endpoint from your application or a log-forwarding script:

curl -X POST http://localhost:8080/ingest \
  -H "Content-Type: application/json" \
  -d '{
    "timestamp": "2026-03-30T14:22:00Z",
    "level": "ERROR",
    "service": "auth-service",
    "message": "Database connection timeout during user authentication"
  }'

You can then filter logs by selecting a time window and searching for keywords like "connection timeout".

If you want to receive notifications when database errors spike, you can set a threshold alert inside LogFloor. When the count of logs matching your search criteria exceeds your specified threshold within a set time frame, LogFloor executes a POST request to your designated webhook URL.

What It Does Not Do

LogFloor is designed strictly for simple log aggregation and basic alerting. It deliberately omits features found in larger logging infrastructure:

No managed cloud offering: You receive the source code and run it yourself; there is no hosted version or managed support.
No high-throughput distributed database: SQLite is not designed for massive horizontal scaling or continuous, multi-gigabyte-per-second write rates.
No native third-party alert channels: Alerting is strictly limited to sending a payload to a target webhook URL. Integrating with platforms like Slack, PagerDuty, or email requires a receiving endpoint that handles the webhook.
No built-in log parsing or transformation pipelines: LogFloor accepts input at its HTTP endpoint; it does not parse unstructured raw text logs, mutate fields, or run agent-based log collection natively. Pre-formatting must be handled before ingestion.

Get it here

Disclosure: I built this and it is a paid product.

Hosted logging services quickly become expensive

IndieSquadTools — Sat, 01 Aug 2026 00:15:28 +0000

Hosted logging services quickly become expensive. Most charge monthly subscription fees based on ingestion volume or retention windows. For smaller projects or simple server setups, paying a recurring monthly bill just to grep through application logs or receive an alert when errors spike is hard to justify. On the other hand, self-hosting complex observability stacks often requires running dedicated database clusters that consume significant memory and compute resources.

I built LogFloor because I wanted basic log search and threshold alerting on my own servers without paying a subscription. It is a lightweight, self-hosted application that ships directly as source code for a one-time cost of $49.

LogFloor uses SQLite as its backend database, which means there are no managed database services to pay for or separate database servers to maintain. Interacting with the system centers on three core components: a single HTTP ingest endpoint, a search UI, and webhook alerts.

Usage Example

To ship logs from your application or system scripts, send an HTTP POST request to LogFloor's ingest endpoint:

curl -X POST https://your-logfloor-instance.com/ingest \
  -H "Content-Type: application/json" \
  -d '{
    "message": "ERROR: Database connection failed",
    "service": "api-gateway"
  }'

From the LogFloor user interface, you can work with your stored logs:

Keyword and time-range search: Filter your log history by entering search terms and specifying start and end time boundaries.
Threshold alerting: Set up alerts that monitor incoming logs against defined thresholds. When a specific rule triggers—such as a keyword exceeding a set count within a designated time window—LogFloor sends a payload to the webhook URL you provided.

What It Does Not Do

LogFloor is designed for basic requirements and omits many features found in larger logging platforms:

It is not a hosted SaaS: There is no cloud dashboard provided by us. You are responsible for provisioning the server, running the application, and securing the instance.
It does not support distributed storage or clustering: Storage is backed entirely by a single SQLite database file, making performance and capacity dependent on single-disk write speeds and SQLite's concurrency limits.
It does not perform complex log parsing or distributed tracing: There are no built-in log parsing pipelines, trace aggregations, or visualization dashboards beyond time-range and keyword searches.
It offers no native third-party notification integrations: Alerts are strictly delivered via HTTP POST requests to a configurable webhook URL. Integrations with services like Slack, Email, or PagerDuty must be handled via custom webhook endpoints or middleware.

LogFloor is available for $49 as a self-hosted package with full source code included.

Get it here

Disclosure: I built this and it is a paid product.

## LogFloor — Self-Hosted Log Search & Alerting

IndieSquadTools — Thu, 30 Jul 2026 23:32:00 +0000

LogFloor — Self-Hosted Log Search & Alerting

LogFloor is $49 once, self-hosted, no per-seat pricing and no monthly bill.

A lightweight, self-hosted log search and alerting tool. Ships as source you run yourself: one HTTP ingest endpoint, keyword and time-range search, and threshold alerts that fire to a webhook URL you choose. SQLite-backed, so there is no managed database bill.

What it is

A self-hosted tool you run yourself. No subscription, no account, no data leaving your machine. You get the source and a licence to use and modify it.

Honest limitations

It is deliberately small. If you need a managed service with a team behind it, this is not that — and the README lists exactly what it does not do before you buy.

Get it here

Disclosure: I built this and it is a paid product.

Debugging inbound webhooks locally without a tunnel

IndieSquadTools — Thu, 30 Jul 2026 21:00:09 +0000

Testing an inbound webhook is annoying in a way that's out of proportion to the problem.

A provider — Stripe, GitHub, Shopify, whatever — will POST a JSON body to a URL you own. You need to see exactly what they send, and you need to send it again after you change your handler. Neither of those is hard. But the usual setup is:

Start a tunnel so the provider can reach your laptop
Paste the generated URL into the provider's dashboard
Trigger the event in their UI
Read your application logs and hope you logged enough
Change your handler
Go back to step 3, because you can't replay what already arrived

Step 6 is the expensive one. Re-triggering a real event through a third party's UI to test a one-line change is a slow loop, and some events aren't easy to trigger on demand at all.

The part you actually need

Strip it down and there are only three requirements:

Capture whatever arrives: method, path, headers, body — unaltered
Inspect it, including the headers, which is usually where the signature lives
Replay it at your handler as many times as you like

None of that requires a tunnel. A tunnel solves a different problem — reachability from the public internet — and once you've captured a payload once, you don't need the provider involved again.

Doing it with the standard library

Python's http.server is enough. A catch-all handler that records the request and returns 200:

from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer

CAPTURED = []

class Handler(BaseHTTPRequestHandler):
    def _capture(self):
        length = int(self.headers.get("Content-Length", 0))
        CAPTURED.append({
            "method": self.command,
            "path": self.path,
            "headers": dict(self.headers),
            "body": self.rfile.read(length).decode("utf-8", "replace"),
        })
        self.send_response(200)
        self.send_header("Content-Type", "application/json")
        self.end_headers()
        self.wfile.write(b'{"status":"captured"}')

    do_POST = do_PUT = do_PATCH = do_GET = do_DELETE = _capture

    def log_message(self, *args):
        pass

ThreadingHTTPServer(("127.0.0.1", 8000), Handler).serve_forever()

Point anything at http://127.0.0.1:8000/hook/test and it's recorded.

Replay is just as plain — take a captured request and send it somewhere else:

import json, urllib.request

def replay(captured, target_url):
    req = urllib.request.Request(
        target_url,
        data=captured["body"].encode(),
        headers={k: v for k, v in captured["headers"].items()
                 if k.lower() not in ("host", "content-length")},
        method=captured["method"],
    )
    with urllib.request.urlopen(req, timeout=10) as resp:
        return resp.status, resp.read().decode()

Dropping Host and Content-Length matters — both refer to the original request and will either be wrong or fight with what urllib sets itself.

That's the whole idea. Everything after this point is convenience: storing more than one request, a UI to read them, matching by endpoint, persisting across restarts.

Things that bite you

Signature verification will fail on replay. Providers sign the raw body, often with a timestamp to prevent exactly this kind of replay. If your handler verifies signatures, you'll need a way to skip verification in development. That's a property of the signature scheme, not something a capture tool can fix.

Read the body exactly once. self.rfile.read() consumes the stream. Read it into a variable first and work from that.

Don't decode blindly. Not every webhook body is UTF-8 JSON. errors="replace" keeps a binary payload from taking down your handler.

Bind to 127.0.0.1. The default in a lot of example code is 0.0.0.0, which puts an unauthenticated endpoint that logs full request bodies — including auth headers — on every interface your machine has.

If you'd rather not maintain it

I got tired of pasting this into projects, so I built it properly and sell it as HookTrap — $49, one-time, source included, no subscription.

It's the same idea with the sharp edges filed off: captures any method to /hook/{endpoint_id}, a built-in web UI at / for reading requests and firing replays, a JSON API (GET /api/requests, POST /api/replay/{id}, DELETE /api/requests), and optional persistence with --file storage.json. Still Python 3.9+ standard library only — no pip install, no account, nothing leaves your machine.

Things it deliberately does not do: no HTTPS of its own (run it behind a proxy if you need TLS), no authentication on the UI, and replays run synchronously so a slow target blocks the call. Those are in the README before you buy, not after.

→ HookTrap — $49, self-hosted

Disclosure: I built HookTrap and it's a paid product. The code in this post is standard library only and yours to use — the article works fine without buying anything.