Monoscope: Observability on S3 with natural language queries

Why S3 storage changes the cost model

Monoscope solves a specific cost problem: storing years of logs, traces, and metrics in a dedicated observability vendor is expensive. The README positions S3-compatible buckets as the primary storage backend, meaning you bring your own bucket and pay only for object storage. That is a real architectural difference from typical observability platforms that use their own hot storage tiers. The trade-off is that you manage the bucket lifecycle, retention policies, and access controls yourself. The documentation does not specify how Monoscope handles bucket versioning, lifecycle transitions, or eventual consistency, so those are open questions for a production deployment. For teams already on AWS S3, MinIO, or similar, this could cut storage costs dramatically, but it also shifts operational burden onto you.

Architecture: Haskell backend, OTLP ingestion, and a stable CLI

The primary language is Haskell, which is unusual for an observability tool. The README does not explain the internal architecture beyond stating that telemetry is stored in S3. It mentions OpenTelemetry native support with 750+ integrations, so ingestion likely uses the OTLP protocol. The CLI is a central component: it emits stable JSON envelopes for every command, enabling agentic pipelines. The README shows a three-step workflow: get a service name via `monoscope facets`, search for an error event, then pull surrounding context with `monoscope events context --window 5m --summary`. The output shapes are documented in a table, which is a strong signal of design discipline. However, the README does not describe how the S3 index is built, how queries are translated to object storage scans, or whether there is a local cache. Without that, you cannot estimate query latency or cost per query.

Getting started: docker-compose and a test-data CLI

The quick start is simple: clone the repository, run `docker-compose up`, and visit `http://localhost:8080` with default credentials admin/changeme. That is a low-friction entry, but the README does not mention any environment variables, bucket configuration, or required IAM permissions. You will need to figure out how to point Monoscope at your S3 bucket from the documentation, which is not in this article. Once running, you can send test data: `monoscope auth login` followed by `monoscope send-event -m "Hello from Monoscope"` for a single event, or `monoscope telemetrygen --kind=trace --rate=5 --count=50` for sustained load. The CLI install script is `curl https://monoscope.tech/install.sh | sh`. That is a typical pattern, but the README does not specify the supported OS or whether the CLI is a binary or a Haskell build.

Natural language queries and the LLM dependency

The core selling point is querying telemetry in plain English via LLMs. The README gives an example of a Claude Code skill that translates a request like "investigate the 500 errors in payment-api" into a CLI pipeline. The MCP server exposes a `search_events_nl` tool that converts natural language to KQL. This is a double-edged sword. LLM-based query translation can be convenient, but it introduces nondeterminism and potential cost per query. The README does not state which LLM provider is used, whether it runs locally, or how errors in translation are handled. If you query a misspelled service name or an ambiguous time range, the LLM might produce a wrong KQL query. The CLI's stable JSON envelopes mitigate this by letting you inspect each step, but the natural language layer remains a black box. For teams that require deterministic query semantics, this is a risk.

AI agents and email reports: scheduled anomaly detection

Monoscope includes AI agents that run on a schedule to detect anomalies and send daily or weekly email reports. The README mentions this as a core capability, but it does not describe how agents are configured, what anomaly detection algorithms are used, or how false positives are handled. The cloud version supports Slack and PagerDuty alert channels, while self-hosted only has basic email. That is a significant limitation for on-call workflows. The agentic pipeline in the CLI is more concrete: each command emits a stable JSON envelope, so you can chain discovery, search, and triage without manual parsing. The README shows a Claude Code skill that runs an on-call sweep, which suggests the agents are more about automating investigation than real-time alerting. If you need paging or escalation, self-hosted Monoscope will not cover it out of the box.

MCP server and agent integration

Monoscope exposes a Model Context Protocol server at `/api/v1/mcp`, which any MCP-aware client can use. The README provides a JSON config snippet for Claude Desktop or Cursor, using a bearer token. Every public REST endpoint is auto-registered as a verb-first tool like `list_monitors` or `search_events`. That is a clean way to expose the platform to AI agents without building custom integrations. However, the README does not list which endpoints exist or how authentication is scoped. The MCP server is a different surface from the CLI: it is HTTP-based, while the CLI is a local binary. Both produce structured output, but the MCP server likely has different rate limits and error handling. For teams building custom agents, this is a useful integration point, but you should verify the tool catalog in `docs/mcp.md` before relying on it.

Limitations and when Monoscope is the wrong tool

The most obvious limitation is the self-hosted alerting: only basic email, no Slack or PagerDuty. If your incident response depends on paging, this is a dealbreaker. Second, the README does not mention any data retention or lifecycle management for S3 buckets. You are responsible for that, and if you do not set up lifecycle rules, your storage costs will grow. Third, the project is written in Haskell, which is a niche language. That could make it harder to find contributors or debug issues. Fourth, the natural language query feature relies on LLMs, which means you need an external API key or a local model, neither of which is documented in this article. Finally, the AGPL-3.0 license is a real constraint: if you modify the code and offer it as a service, you must release your changes. That is not a problem for internal use, but it matters for vendors.

Alternatives and where Monoscope stands

The closest alternative is Grafana with Loki, Tempo, and Mimir, which also support object storage (S3, GCS, Azure Blob) for logs, traces, and metrics. Grafana has a mature query language (LogQL, PromQL, TraceQL) and a huge ecosystem, but it does not have built-in natural language queries or AI agents. Another alternative is SigNoz, which is OpenTelemetry-native and offers a self-hosted option, but it uses ClickHouse for storage, not S3 directly. The difference in approach is fundamental: Monoscope puts S3 as the primary storage and relies on LLMs for query translation, while Grafana and SigNoz use dedicated query engines with their own indexes. That means Monoscope may be cheaper for cold storage but likely slower for ad-hoc queries that scan large ranges. If you need deterministic, high-performance queries, a dedicated engine is safer. If you want to minimize storage costs and are willing to trade query speed and determinism, Monoscope is a distinct option.

Maintenance, license, and upgrade path

The project is actively maintained: the latest release is v0.6.25 from August 2026, with previous releases in June and July of the same year. That suggests a regular release cadence, but the README does not include a changelog or migration notes. Upgrading a Haskell service may require rebuilding from source if you self-host, since there are no prebuilt binaries mentioned. The AGPL-3.0 license is copyleft, so any modifications you distribute as a network service must be open-sourced. That is a legal consideration, not advice. The CLI and MCP server are documented with stable JSON envelopes, which should reduce breakage when upgrading, but the LLM integration may change as providers update their APIs. Before adopting, check the `docs/` directory for upgrade instructions and breaking changes, as the README does not cover them.

Editorial conclusion

Adopt Monoscope if you already run S3-compatible storage, want multi-year telemetry retention at low cost, and are comfortable with an AGPL-3.0 codebase written in Haskell. Do not adopt it if you need managed auth/SSO, advanced alert channels, or a mature ecosystem with extensive documentation. Before committing, verify the self-hosted deployment path with docker-compose, test the natural language query accuracy on your own data, and confirm the CLI and MCP tooling cover your incident workflows. The project is actively released (v0.6.25 as of August 2026), but its reliance on LLMs and a young codebase means you should validate the query pipeline against your specific telemetry shapes first.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes