Forem: Robel Kidin T

The hidden infrastructure you build when you ship AI chat

Robel Kidin T — Fri, 01 May 2026 05:48:59 +0000

A chat textarea is a 30-minute build. The persistence, streaming reassembly, dedup, tool-call audit trail, and history endpoint that turn it into a real product is 3+ weeks. A walkthrough of what breaks, in what order, and how to skip most of it.
qlaud team
·
Engineering
I added a chat UI to my app in 30 minutes. The actual chat infrastructure took three weeks. This post is what those three weeks were spent on, in what order each piece broke, and how I'd shortcut most of it if I were starting over.

If you've shipped AI chat before, you know what I'm about to describe. If you haven't yet, this is the post I wish I'd read first — half warning, half tutorial, with a path through the swamp at the end.

What "ship AI chat" actually means

A chat box is a textarea, an for streaming, and a list of message bubbles. That's the part that takes 30 minutes. Then real users start using it and you discover everything chat needs to be a real product:

Stream reassembly when the connection drops mid-response
Persistence so refresh doesn't lose the conversation
Deduplication when the user retries on a 5xx
Tool calls that need to be auditable in conversation history
Per-user sequencing so two browsers don't desync
A history endpoint, sortable + paginated, with backpressure
Cleanup of dangling streams that the client never closed
A schema that doesn't fall apart when you add models with different shapes
Each of these is a fixable problem. The aggregate cost is what surprises you.

What breaks first: streaming reassembly on flaky networks

Your first beta tester closes their laptop mid-response. They reopen ten minutes later. The chat shows a half-finished assistant message ending in "Therefore, the optimal strate—" and that's it. Reload the page; the half-message is gone, no recovery, no resume.

The fix is buffering the stream server-side, not just relaying it. You need a server endpoint that:

Receives chunks from the upstream model
Forwards them to the client over an SSE/websocket
Also writes them to durable storage as they land
On client reconnect, replays whatever was buffered + continues the live stream
That's a non-trivial pattern. Cloudflare Durable Objects work well for it (single-writer, replicates across reconnects). Postgres + Listen/Notify works too if you commit to managing the connection pool. AWS uses a combination of API Gateway WebSockets + DynamoDB streams.

Whatever you pick, you've now committed to a specific infra primitive that's load-bearing in the hot path of every chat interaction. Pick wrong here and you're refactoring it in 6 months when the reconnect story leaks at scale.

What breaks second: the persistence schema

OK, you persist messages now. What's the schema?

The naive version:

-- v1 schema

CREATE TABLE messages (
  id        uuid PRIMARY KEY,
  thread_id uuid NOT NULL,
  role      text NOT NULL,  -- 'user' | 'assistant'
  content   text NOT NULL,
  created_at timestamptz NOT NULL DEFAULT now()
);
That

works for two days. Then you discover:

Multi-modal content. "Content" isn't just text — it's an array of blocks: text, image, tool_use, tool_result. Now you need either JSONB or a separate message_blocks table.

Token counts. You need them for billing, retention, rate limiting. They have to land on the message row at the moment the stream completes, which is a separate event from when you first inserted the row. You either eagerly upsert them (hot-path write contention) or eventually-update via background job (eventual consistency in your UI).

Sequencing. Two browser tabs send a message concurrently. You need a strict ordering. Naive auto-incrementing integer doesn't work across writers; UUIDs don't sort; clock-based ordering breaks under skew. You end up with a per-thread sequence number that requires a row lock or a Durable Object.

Per-end-user scoping. If you're building a B2B product where companies have many end-users, you need to scope every query by end_user_id. Add a column, add an index, add an explicit WHERE clause to every read path. Forget one and you have a tenant-leak bug.

Schema v3, eight commits later, looks more like:

CREATE TABLE threads (
  id          uuid PRIMARY KEY,
  user_id     text NOT NULL,
  end_user_id text NOT NULL,
  metadata    jsonb,
  created_at  timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE thread_messages (
  thread_id    uuid NOT NULL REFERENCES threads(id),
  seq          integer NOT NULL,  -- per-thread sequence
  role         text NOT NULL,
  content      jsonb NOT NULL,    -- array of blocks
  request_id   text,              -- for dedup
  token_count  integer,
  created_at   timestamptz NOT NULL,
  PRIMARY KEY (thread_id, seq)
);

CREATE INDEX idx_thread_messages_thread_id ON thread_messages(thread_id);
CREATE INDEX idx_threads_end_user ON threads(end_user_id);
Plus migrations. Plus a backfill plan when you change anything. Plus rate-limited cleanup of orphaned threads. Plus a vacuum strategy for the inevitable bloat.

What breaks third: tool calls that vanish from history

Then you add tool calling. The model emits a tool_use block ("call get_weather('SF')"). Your code dispatches the tool, gets a result ("72°F, sunny"), feeds it back into the next request as a tool_result block.

Question: do you persist those tool_use and tool_result blocks?

First reaction: "no, those are internal — only show user-visible messages." Two weeks later: a user asks "why did the AI tell me my appointment was at 3pm? It should have said 2pm." You go to debug it. You can see the user's message ("when's my appointment?") and the assistant's reply ("3pm"). You CAN'T see the get_calendar tool call, what it returned, or whether it errored.

Tool call history isn't optional. It's THE audit trail when an agent makes a wrong decision. Persist it. Now your thread_messages content blocks include four kinds: text, image, tool_use, tool_result. Your read paths have to filter to user-visible content unless an admin is debugging.

What breaks fourth: deduplication

The user sends a message. Your client gets a 502 from your edge worker (CDN hiccup, container restart, whatever). The client retries. Now you have two identical user messages in the thread.

Dedup is per-request-id, not per-content. Generate an idempotency key client-side, send it as a header, persist it as a column, fail gracefully on conflict. Easy to describe, easy to forget, hard to retrofit into a system that already has dirty data.

What breaks fifth: the history endpoint

Your client needs to load past messages on page refresh. So you write GET /api/threads/:id/messages. Easy. It returns a JSON array of messages.

Then a power user has a 6,000-message conversation. Your endpoint returns 12MB of JSON. The browser hangs while parsing. You add ?limit=50. Now you need cursor-based pagination because offset-based starts skipping messages when new ones arrive while scrolling. You write the cursor encoding, decode it, validate it, handle malformed cursors gracefully. Another two days.

The accumulated cost

Let's tally:

Streaming reassembly + buffer: ~2 days
Persistence schema (with the migrations to get to v3): ~3 days
Tool call history: ~1.5 days
Deduplication: ~0.5 days
History endpoint with cursor pagination: ~1 day
Per-end-user scoping audit (going through every endpoint): ~1 day
Bug fixes from production usage: ~3 days
Vector search for "find past conversation about X" (Pinecone setup, embedding pipeline): ~2 days
Total: ~14 days of senior engineer time, conservatively. Plus the ongoing cost of maintaining all of it as your model providers add new block types, your schema needs new fields, and you have to keep migrations + backfills consistent.

That's the time you spent NOT shipping product features. For the chunk of teams whose differentiation is the chat application — not the infrastructure — this is dead weight.

The shortcut: a managed thread API

Most of the above isn't novel. Every team building AI chat re-derives the same pattern. So somebody had to write the gateway version, and qlaud's threads API is what we ship for it. Two endpoints replace the entire stack:

Create a thread

curl https://api.qlaud.ai/v1/threads \
  -H "Authorization: Bearer qlk_live_…" \
  -d '{ "end_user_id": "user_42", "metadata": { "topic": "support" } }'
Send a message — streams + persists in one call

curl https://api.qlaud.ai/v1/threads/{id}/messages \
  -H "Authorization: Bearer qlk_live_…" \
  -d '{
    "model": "claude-sonnet-4-6",
    "stream": true,
    "content": [{ "type": "text", "text": "What's my plan?" }],
    "tools_mode": "tenant"
  }'
Fetch sequenced history

const { data } = await qlaud.threads.messages({
  thread_id: "thread_eace4f23",
});

// → ordered messages, with text + tool_use + tool_result blocks intact
// → token counts, request_ids, end_user_ids all there
// → automatic dedup, cursor pagination via ?limit + ?cursor
What you get for free, in order of "what would otherwise have taken you a week":

Streams that don't lose data. Server-side buffering of every chunk as it lands. Reconnect = resume; refresh = full history. No half-finished messages.
Tool calls persisted as first-class history. Every tool_use and tool_result block lands in the same conversation record. Audit trails, debugging, agent retry logic — all become readable.
Sequencing per end-user. Each thread carries anend_user_id; messages get a per-thread sequence number; two browsers writing to the same thread don't desync.
Deduplication on request-id. Retries don't double-write. 5xx-then-retry just hits the same message slot.
Vector search built in. Every assistant message gets embedded and indexed. GET /v1/search returns semantically similar past messages — no Pinecone integration, no embedding pipeline.
Cross-model. Claude, GPT, DeepSeek, Gemini, etc. Same thread can flip models mid-conversation; the history shape stays consistent.
Time to integrate: roughly the same 30 minutes as the original chat textarea. The 14 days of stack-building skipped.

When to roll your own anyway

I'm not arguing nobody should build their own chat backend. The honest framing is: build it when chat infrastructure is your competitive advantage. Notion, Linear, Slack — those companies own their persistence layer because the database IS the product.

For everyone else — and that's most teams — the persistence layer is a tax. You pay it because you have to, and you'd rather pay $15/month for someone else to operate it than pay 14 days of senior eng time + ongoing on-call.

Some heuristics for when to take on the work yourself:

You need data residency in a specific region that no gateway offers (uncommon — most ship on Cloudflare, AWS, or GCP edge).
Your conversation messages are 100KB+ each (rich embedded media that doesn't fit JSON). Most managed stacks have row size limits around 64-128KB.
You need millisecond-tight read latency (e.g., autocomplete). Most managed gateways are P99 ~50-150ms. Below that requires colocation.
Compliance audit requires that no data ever leaves your infra. Some healthcare and government contracts require this.
If none of those apply, the math is straightforward. Use the managed version, ship the actual product.

The bottom line

Shipping AI chat is shipping ~12 features wearing a textarea costume. The textarea is one feature. The other eleven take three weeks. Most teams either ship without them (which feels hacky), or build them all (which delays the product). The third option — outsource the eleven so you can focus on the textarea your users actually see — is the one I wish I'd taken from day one.

If you want to try the gateway version, qlaud has a free tier with $200 starter credit and works with the OpenAI / Anthropic / ElevenLabs SDKs you already use. The threads API is documented at docs.qlaud.ai/api-reference/threads; the recipe book for tools is at docs.qlaud.ai/api-reference/tool-examples.

Or build it yourself. Just count the days first.

ai chat persistence

ai chat streaming

How I cut my AI app's OpenAI bill 60% with per-user API keys

Robel Kidin T — Fri, 01 May 2026 05:45:25 +0000

A $5,247 bill I couldn't attribute. The naive Postgres approach that didn't scale. The per-user-keys pattern that fixed it — with the actual numbers, code, and the 60% cost reduction in 6 weeks.
qlaud team
·
Engineering
Last month my OpenAI bill was $5,247. I'd budgeted $1,000. The Stripe email landed at 6:30 AM and I sat there refreshing the page, because there was no way that number could be right.

It was right. And the worst part wasn't the size of the bill — it was that I had no idea which user did it. OpenAI's dashboard showed the aggregate; my own logs showed thousands of requests; I couldn't connect the two. By the time I'd traced it (one user, automation script, ~60 requests/min for two days), the damage was done.

Six weeks later my AI bill is $1,650 — a 60% reduction — with the same product features and growing user base. This post is what I changed, with the actual code, the math, and the architecture decisions that mattered. Most of it boils down to one pattern: per-user API keys with hard spend caps.

The naive approach I tried first (and why it failed)

My first instinct was to add cost tracking myself. Postgres table:requests(user_id, model, input_tokens, output_tokens, cost_micros, created_at). Every request logs a row. Sum by user_id. Done.

It was not done. Three things broke:

Streaming responses don't tell you the token count until the end

When you stream from OpenAI, you don't know completion_tokens until the stream finishes. If the request is canceled mid-stream, you have to count tokens yourself from the chunks you received. I got this wrong twice — first by under-counting (the canceled-stream case), then by double-counting (when I added a retry on transient 5xx errors and didn't dedupe).

Caps need to be enforced BEFORE the request fires, not after

The "log every request and sum it up" approach is observability, not enforcement. The runaway user could already have burned $400 by the time my nightly cron noticed. To enforce a cap I'd need a synchronous read before every request — which means a Postgres lookup in the hot path of every API call, which is its own performance problem.

Cross-provider attribution turns into a special-case nightmare

I wasn't just on OpenAI. Anthropic Claude for some flows, DeepSeek for others. Each provider has different pricing, different streaming shapes, different ways of counting tokens (Anthropic counts cache reads separately, OpenAI bundles them). My single Postgres rollup needed provider-specific pricing logic + token-counting code per shape. Every new model I added meant new code in the metering path.

Around week two of this rabbit hole I realized I was building the wrong layer. What I actually wanted was a gateway that did the metering for me, so my application code could go back to being application code.

The pattern: per-user API keys with hard caps

Stripe Connect, AWS IAM sub-accounts, GitHub fine-grained PATs — every modern tenant-scoped infra primitive uses the same pattern. You hold one master credential. You mint child credentials per user, each with their own scoped permissions and limits. Cost tracking and access control fall out automatically because they're defined at the credential level.

For AI inference, this looks like:

You sign up for qlaud (or build your own gateway). You get one master key.
On every user signup in YOUR app, you mint a per-user child key with a $10 cap.
That user's requests carry their own key. The gateway enforces the cap before forwarding.
You pull per-user usage at month-end and bill however you want.
The end-to-end code is roughly 30 lines:

Step 1 — Mint a key on signup

At user signup, server-side
const userKey = await qlaud.keys.create({ user_id: user.id, name: user.email, scope: "standard", max_spend_usd: 10, // hard cap — this is the magic });

await db.users.update(user.id, { qlaud_key: userKey.secret, });

Step 2 — Use the per-user key in the official OpenAI SDK

`import OpenAI from "openai";

Per-request, get the user's stored key from your DB
const client = new OpenAI({
baseURL: "https://api.qlaud.ai/v1",
apiKey: user.qlaud_key,
});

const completion = await client.chat.completions.create({
model: "gpt-5.4",
messages: [...],
stream: true,
});`

That's the whole client-side change. The OpenAI SDK doesn't know it's hitting a gateway. Same response shape, same error handling, same streaming — only the baseURL changed. Anthropic SDK works the same way (set ANTHROPIC_BASE_URL=https://api.qlaud.ai).

Step 3 — When a user hits the cap, return 402 cleanly

qlaud automatically returns 402 Payment Required when a user's cap is exhausted. In your UI, catch that response and surface an upgrade prompt:

try { const completion = await client.chat.completions.create(...); } catch (err) { if (err.status === 402) { showUpgradeModal({ message: "You've hit your daily AI credit limit. Upgrade to keep going.", planLink: "/pricing", }); return; } throw err; }

Step 4 — Pull usage at month-end

const usage = await fetch("https://api.qlaud.ai/v1/usage?from_ms=...&to_ms=...", { headers: { Authorization:Bearer ${process.env.QLAUD_MASTER_KEY}` },
}).then(r => r.json());

// usage.by_key[].cost_micros — divide by 1_000_000 for dollars
for (const k of usage.by_key) {
await stripe.invoiceItems.create({
customer: getStripeCustomerByQlaudUser(k.user_id),
amount: Math.ceil(k.cost_micros / 10_000), // markup baked in
currency: "usd",
});
}`

Whatever margin you want is between you and your customer. qlaud charges you upstream cost + 7% gateway fee. Your invoice line items can be per-token, per-feature, flat tier with usage allowance — your call.

What changed in 6 weeks (the real numbers)

Here's what happened to the bill week-by-week after I made the switch. These are real numbers from my dogfood usage on qlaud — same product, same growing user base.

`Week Bill ($) Active users Notes

0 5,247 74 baseline (the $5K shock month)
1 3,180 78 user_42 hit their $10 cap on day 2
2 2,720 85 5 users hit caps; 3 upgraded to paid
3 2,340 91 added cap-warn email at 80%
4 2,015 97 tightened tier defaults: $5 free, $25 paid
5 1,810 104 churn cleaned up — bad-actor user gone
6 1,650 112 steady state`

Couple of observations from the numbers, since they're worth more than the percentage drop in isolation:

The runaway user got contained immediately. Day 2 of week 1, user_42 hit the cap. Their script kept retrying and getting 402'd. Total spend on that user for the month: $10. Previous month: estimated $1,800.
Caps surface upgrade signal. Five users hit caps legitimately in week 2 — power users actually using the product. Three of them upgraded when shown the modal. That's a 60% upgrade-on-cap-hit rate that I had no way to surface before. New-feature: hitting the cap is now my best lead source.
Tier defaults compounded. Once I knew per-user spend patterns I could redesign the free tier. Free went from "$10 generous" to "$5 limited"; paid tier ($19/mo) gets $25 of usage. Conversion went up because the free tier hits cap faster, and average revenue per paid user is now higher than the gross AI cost. Sustainable unit economics for the first time.
What this unlocks beyond cost control

The killer feature isn't the 60% reduction. It's that per-user attribution is now a primitive in my product, and that primitive composes:

Cohort analysis

Group users by signup date, plan, geography, referral source. For each cohort, see "average cost per user", "% of users who hit cap", "median time to first dollar of value." This is the kind of analysis that turns gut-feel pricing into actual unit economics.

Anomaly detection

A user spending 10x the cohort median in week 1? Either they're a power user (good signal — reach out, offer a custom plan) or a bad actor (also good signal — review and ban before they cost you money).

Granular feature pricing

Previously I priced features in averages: "AI features cost about $0.05 per use." Now I have actual numbers: image-gen costs $0.04, summarization costs $0.003, agent loop costs $0.18. Pricing decisions stop being guesses.

Per-user model routing

For free-tier users, route to DeepSeek V3 ($0.27/MTok in). For paid, route to Claude Sonnet 4.6 ($3/MTok in). The cost-per-user gap shrinks 10x without changing the perceived product quality much.

Things I'd do differently if starting over

A few decisions in retrospect — short list because hindsight is long-winded:

Mint per-user keys from day one, not after the $5K shock. The cost of adding it later is dealing with one messy migration; the cost of not having it from day one is one bad-actor user away.
Default the free-tier cap lower — start at $3, not $10. People who care will pay; people who don't were never going to pay.
Build the cap-warn email at 80% on day one, not week 3. Users who hit cap unexpectedly churn; users who get warned and given a clear upgrade path convert.
Use the gateway's response time-series, not just spend. Latency-by-user surfaces issues spend doesn't (a user hitting slow paths repeatedly = something to fix in the product).
The takeaway

Per-user AI cost attribution stops being an afterthought when you make it a credential primitive. Mint a key per user, cap it, drop into the official SDK, pull usage at month-end. That's the playbook. The infrastructure to do this yourself is doable but distracting; the infrastructure to do it via qlaud is one signup and a base-URL change away.

Free tier with $200 starter credit if you want to kick the tires. Drop-in compatible with the OpenAI, Anthropic, ElevenLabs, Vercel AI, LangChain, and LlamaIndex SDKs. The first-month bill anomaly is the one you'll never have again.

How We Built an AI SRE That Replaces Your Log Dashboard

Robel Kidin T — Thu, 12 Mar 2026 17:07:52 +0000

TL;DR: We built an open-source platform that ingests logs via OpenTelemetry, detects anomalies using statistical analysis, and auto-creates incident tickets with root cause analysis — in about 90 seconds. It's called LogClaw. Apache 2.0 licensed. You can run docker compose up -d and have a full stack in minutes.

The Problem: Log Dashboards Are Broken

The industry average Mean Time to Resolution (MTTR) is 174 minutes. Most of that isn't fixing the problem — it's finding it.

Here's what a typical incident looks like:

PagerDuty fires at 3 AM (threshold alert you set 6 months ago)
You open Datadog/Splunk/Grafana
You spend 45 minutes grepping through dashboards
You find the error, but not the cause
You spend another hour tracing across services
You open a Jira ticket manually and paste log lines
You fix the bug

Steps 2-6 are waste. A machine should do them.

That's what we built.

The Architecture

LogClaw is a Kubernetes-native log intelligence platform. Here's the data flow:

Your App (OTEL SDK)
    ↓ OTLP (gRPC :4317 or HTTP :4318)
OTel Collector (batching, tenant enrichment)
    ↓
Kafka (Strimzi, KRaft mode)
    ↓
Bridge (Python, 4 concurrent threads)
    ├── OTLP ETL (flatten JSON, normalize fields)
    ├── Anomaly Detection (z-score on error rate distributions)
    ├── OpenSearch Indexer (bulk index, ILM lifecycle)
    └── Trace Correlation (5-layer request lifecycle engine)
    ↓
OpenSearch (full-text search, analytics)
    +
Ticketing Agent (RCA via LLM → Jira/ServiceNow/PagerDuty/Slack)

The key insight: the Bridge runs 4 threads concurrently — ETL normalization, signal-based anomaly detection, OpenSearch indexing, and trace correlation with blast radius computation. When the anomaly detector's composite score exceeds the threshold (combining 8 signal patterns, statistical z-score, blast radius, velocity, and recurrence signals), it triggers the Ticketing Agent, which pulls relevant log samples and correlated traces, sends them to an LLM for root cause analysis, and creates a deduplicated ticket across 6 platforms.

Sending Logs (2 Lines of Code)

LogClaw uses OpenTelemetry as its sole ingestion protocol. If your app already emits OTEL, you just point it at LogClaw.

Python:

from opentelemetry.sdk._logs import LoggerProvider
from opentelemetry.sdk._logs.export import BatchLogRecordProcessor
from opentelemetry.exporter.otlp.proto.http._log_exporter import OTLPLogExporter

exporter = OTLPLogExporter(
    endpoint="https://otel.logclaw.ai/v1/logs",
    headers={"x-logclaw-api-key": "lc_proj_your_key"},
)
provider = LoggerProvider()
provider.add_log_record_processor(BatchLogRecordProcessor(exporter))

Node.js:

const { OTLPLogExporter } = require('@opentelemetry/exporter-logs-otlp-http');

const exporter = new OTLPLogExporter({
  url: 'https://otel.logclaw.ai/v1/logs',
  headers: { 'x-logclaw-api-key': 'lc_proj_your_key' },
});

Java (zero code changes):

java -javaagent:opentelemetry-javaagent.jar \
  -Dotel.exporter.otlp.endpoint=https://otel.logclaw.ai \
  -Dotel.exporter.otlp.headers=x-logclaw-api-key=lc_proj_your_key \
  -jar my-app.jar

Anomaly Detection: Signal-Based, Not Threshold-Based

Most monitoring tools require manual alert thresholds. "Alert me when error rate > 5%." But that approach fails in three ways: it treats validation errors the same as OOM crashes, it can't detect failures before a 30-second window completes, and it misses services with constantly elevated error rates.

LogClaw uses a signal-based composite scoring system — not just z-score. Every error log flows through three stages:

Stage 1: Signal Extraction — 8 language-agnostic pattern groups with weighted severity:

Signal	Weight	Example
OOM	0.95	`OutOfMemoryError`, `malloc failed`
Crash	0.95	`segfault`, `panic`, `SIGSEGV`
Resource	0.80	`disk full`, `fd limit reached`
Dependency	0.75	`502 Bad Gateway`, service unavailable
Database	0.75	`deadlock`, `connection pool exhausted`
Timeout	0.70	`deadline exceeded`, `ETIMEDOUT`
Connection	0.65	`ECONNREFUSED`, `broken pipe`
Auth	0.40	`access denied`, `token expired`

Stage 2: Composite Scoring — Six categories combine into a single score:

Pattern matches (30%) + Statistical z-score (25%) + Contextual signals (15%) + HTTP status (10%) + Log severity (10%) + Structural indicators (10%)

The contextual signals use 300-second sliding windows to compute:

Blast radius: How many services are simultaneously erroring (5+ services = 0.90 weight)
Velocity: Error rate acceleration vs. historical average (5x spike = 0.80 weight)
Recurrence: Novel error templates score higher than known patterns

Stage 3: Dual-Path Detection

Immediate path (<100ms): OOM, crashes, and resource exhaustion fire instantly — no waiting for time windows. Your payment service crashes at 3 AM, and there's a ticket before the process restarts.
Windowed path (10-30s): Statistical anomalies detected via z-score analysis on sliding windows.

The result: 99.8% detection rate for critical failures, with near-zero false positives. Validation errors (400s) and 404s produce scores below the 0.4 threshold — they never trigger incidents.

5-Layer Trace Correlation

When an anomaly fires, the Bridge's Request Lifecycle Engine constructs a complete request timeline using 5 correlation layers:

Trace ID clustering — Groups related logs across services
Temporal proximity — Associates logs within the same time window
Service dependency mapping — Maps caller → callee relationships
Error propagation tracking — Traces the cascade from root cause to symptoms
Blast radius computation — Identifies all affected downstream services

This is what turns "your payment service has errors" into "Redis connection pool exhausted in checkout handler → payment-api failing → order-service timing out → notification-service queue backing up."

Auto-Ticketing: From Anomaly to Jira in 90 Seconds

When the composite score exceeds the threshold, the Ticketing Agent:

Pulls relevant log samples + the correlated trace timeline from OpenSearch
Sends them to your LLM (OpenAI, Claude, or Ollama for air-gapped deployments)
Generates a root cause analysis with blast radius and suggested fix
Creates a deduplicated ticket on Jira, ServiceNow, PagerDuty, OpsGenie, Slack, or Zammad

Severity-based routing means critical incidents hit PagerDuty + Slack + Jira simultaneously, while medium severity goes to Jira only.

Your team wakes up to a ticket that says: "Payment service composite anomaly score 0.91 (critical) at 03:47 UTC. Signals: db:connection_pool (0.75), blast_radius:4_services (0.85), velocity:12x_baseline (0.90). Root cause: Redis connection pool exhaustion due to unclosed connections in the checkout handler. Affected services: payment-api, order-service, notification-service, email-service. Suggested fix: Add connection pool max_idle_time configuration and close connections in finally block."

The Cost Problem

Here's what 500GB/day of logs costs across vendors:

Vendor	Annual Cost	Notes
Splunk	~$1,200,000	+ professional services, SPL training
Datadog	~$509,000	+ per-host fees, custom metrics, retention upgrades
New Relic	~$350,000	+ $549/user/month for full platform seats
Elastic Cloud	~$180,000	+ ops team for cluster management
Grafana Cloud	~$90,000	No full-text search (label-only indexing)
LogClaw Cloud	~$54,000	All-inclusive: AI + ticketing + 97-day retention
LogClaw Self-Hosted	~$30,000	Infrastructure only (Apache 2.0, free forever)

LogClaw Cloud charges $0.30/GB ingested. No per-seat fees. No per-host fees. No per-feature add-ons. The AI anomaly detection and auto-ticketing are included.

Try It in 5 Minutes

No Kubernetes required for testing:

git clone https://github.com/logclaw/logclaw.git
cd logclaw
docker compose up -d

Open http://localhost:3000 — full dashboard, anomaly detection, and ticketing.

For production, deploy on Kubernetes with Helm:

helm install logclaw charts/logclaw-tenant \
  --namespace logclaw \
  --create-namespace

Single command gives you: OTel Collector, Kafka, Flink, OpenSearch, Bridge, Ticketing Agent, and Dashboard.

What's on the Roadmap

LogClaw is currently focused on logs. Here's what's coming:

Metrics support — ingest OTEL metrics alongside logs
Trace visualization — distributed trace rendering in the dashboard
Deep learning anomaly models — beyond z-score, using autoencoder models for subtle drift detection
Runbook automation — not just tickets, but auto-remediation scripts

Get Involved

LogClaw is Apache 2.0 licensed. The entire platform is open source.

GitHub: https://github.com/logclaw/logclaw
Docs: https://docs.logclaw.ai
Managed Cloud: https://console.logclaw.ai (1 GB/day free, no credit card)
Book a Demo: https://calendly.com/robelkidin/logclaw

Star the repo if this is useful. Open an issue if you find a bug. PRs welcome.