How Obics works

Obics is an observability cost-optimization platform. Its job is to answer a question most teams can’t answer easily: “Which of my logs and metrics are worth what I’m paying for them, and which aren’t?”, and then to actually fix the ones that aren’t.

The core idea

Every log line and every metric your services emit costs money at your observability vendor. A single overly-chatty log statement, repeated millions of times a month, or one metric tagged with a high-cardinality label like a user ID or IP address, can quietly dominate your bill. These problems live in your source code, so the only durable fix is a code change.

Obics closes that loop:

1. Reads your telemetry from your observability vendor to see what you ingest and what it costs.
2. Groups and ranks it: collapsing millions of near-identical log lines into a handful of log groups, and measuring each metric’s cardinality.
3. Matches each item to your source code: the exact file and line that emits it.
4. Asks an LLM for an optimization (lower the log level, sample it, remove a redundant metric, drop an unused label, and so on) with an estimated saving and a risk rating.
5. Writes the fix as a pull request when you approve it, against your own repository.

What Obics connects to

You connect	Obics uses it to
Observability vendor (Datadog, Grafana, CloudWatch, Coralogix)	Read logs, metrics, volumes and cardinality, and read your dashboards and monitors to know what’s actually in use.
Source code host (GitHub, GitLab, Azure DevOps)	Clone your repos to match telemetry to code, and open pull/merge requests with fixes.

Obics never needs write access to your observability vendor to find problems; it only reads. Write access to your code is what lets it propose fixes.

The two scan pipelines

A scan runs two independent pipelines in parallel: one for logs, one for metrics. You’ll see the results of each on the Optimize Logs and Optimize Metrics pages.

                       A scan starts
                            │
              ┌─────────────┴─────────────┐
              ▼                           ▼
        LOGS PIPELINE               METRICS PIPELINE
              │                           │
   Group logs into clusters      Discover every metric
              │                    and its cardinality
   Match clusters to code                 │
              │                    Find where each metric
   Ask the LLM for an                is emitted in code
   optimization per cluster                │
              │                    Ask the LLM which metrics
              ▼                    are redundant/optimizable
     Log recommendations                   ▼
                              Metric recommendations

Both pipelines end the same way: a ranked list of recommendations you can review, ignore, or turn into a pull request.

Note

An organization can optimize logs, metrics, or both, depending on which observability capabilities you’ve connected and your plan. The free tier covers 50 GB/month of logs plus up to 10 metric insights. See Integrations.

Who does what

Role	Typical actions
Engineer / SRE	Reviews recommendations, approves fixes, opens PRs, manages integrations.
Owner / Admin	Invites teammates, configures scan settings and pricing, manages the organization.
Obics (automated)	Runs the nightly scan, tracks open PRs, resolves fixes when they merge.

Next: Create your account.