Compare Distlang Plan Features — 4 Plans, 2026 Guide

Why a Glossary for Comparing Distlang Plan Features?

Observability pricing has become notoriously confusing. One developer on Team Blind described getting a bill nearly three times what they expected because of hidden fees in their monitoring tool. Traditional vendors bill across multiple dimensions: per host, per custom metric, per GB ingested, per GB indexed. You end up needing a spreadsheet just to forecast your monthly cost.

Distlang Metrics takes a different approach. The pricing page has four tiers, and the differences between them come down to a handful of terms. But if you don’t know what “rows/month” means or why retention matters, you can’t make an informed comparison.

This glossary exists to fix that. Each definition includes what the term means technically, why it matters when choosing a plan, and how Distlang’s approach compares to alternatives. If you want to see the plans themselves, head to the Distlang Metrics product page.

Here’s the plan comparison table for quick reference:

	Free	Launch ($5/mo)	Hobby ($19/mo)	Growth ($79/mo)
Rows/month	500K	1.5M	5M	20M
Retention	7 days	7 days	14 days	30 days
Metric sets	Unlimited	Unlimited	Unlimited	Unlimited
AI suggestions	Included	Included	Included	Included

Now let’s define every term in that table, and the related concepts you’ll need to compare Distlang plan features with confidence.

Plan-Level Terms

Rows/Month

A row is a single data point sent to Distlang. Every time your application records a counter increment or a histogram observation, that counts as one row. Rows per month is the total number of data points you can ingest during a billing cycle.

This is Distlang’s “value metric,” the unit that scales with your usage. The Free plan includes 500K rows/month. Launch bumps that to 1.5M. Hobby gives you 5M, and Growth provides 20M.

Why it matters when comparing plans: Your row consumption depends on how many metrics you track, how many labels you attach, and how frequently your application sends data. A side project hitting a few endpoints might generate tens of thousands of rows per month. A production app with multiple services, rich labeling, and high traffic can generate millions.

How it differs from alternatives: Legacy APM tools often charge per host (which gets confusing in serverless environments where there are no persistent hosts) or per custom metric (which punishes rich instrumentation). Applications with detailed instrumentation can easily generate 10,000 to 50,000+ custom metrics, translating to thousands of dollars per year on traditional platforms. Distlang charges per row ingested, not per unique metric name or per host, which makes costs more predictable.

Data Retention

Retention is how long your metric data stays queryable in the dashboard. After the retention window expires, the data is no longer accessible.

Free and Launch plans both offer 7-day retention. Hobby extends that to 14 days. Growth gives you 30 days.

Why it matters when comparing plans: Seven days is enough if you’re debugging recent deploys or watching real-time traffic patterns. Two weeks (Hobby) lets you compare this week to last week. Thirty days (Growth) is what you need for monthly trend analysis, capacity planning, or reviewing metrics across a full release cycle.

How it differs from alternatives: Some platforms include long retention windows but charge significantly more. Azure Monitor, for example, includes 18 months of metrics retention but at pay-as-you-go rates that add up quickly. Distlang’s approach is transparent: shorter retention equals a lower plan price. You pick the lookback window you actually need.

Metric Sets

A metric set is a named collection of related metrics. Think of it as a logical grouping, for example, all the counters and histograms for your authentication service, or all the latency measurements for your API gateway.

Every Distlang plan includes unlimited metric sets.

Why it matters when comparing plans: It doesn’t gate your decision, and that’s the point. You never have to worry about creating too many metric sets or consolidating unrelated metrics into one set to save money. This contrasts with tools that charge per custom metric, where the key driver of cost is tag cardinality, a metric tagged with high-cardinality dimensions like user_id can generate millions of unique time series and spike your bill.

For a deeper look at how metric sets work in practice, the end-to-end walkthrough shows how one gets created and visualized.

AI Suggestions

Distlang’s dashboard automatically generates chart titles and descriptions based on your incoming metrics. If you send a histogram called request_latency with labels for route and method, the AI will suggest meaningful chart names without you typing anything.

All four plans include AI suggestions. There’s no premium AI tier or add-on.

Why it matters when comparing plans: It removes a common friction point. Many developers skip setting up dashboards because naming and organizing charts feels tedious. AI suggestions make the default dashboard usable from the start. You can learn more about customizing AI chart suggestions once you want to refine the defaults.

Metric Types

When you compare Distlang plan features, you’ll notice that all plans support both metric types equally. Understanding the difference helps you estimate row consumption.

Counter

A counter is a monotonically increasing value. It only goes up (or resets to zero). Common examples: total HTTP requests served, total errors encountered, total bytes transferred.

Counters are lightweight. Each increment is one row. If your endpoint receives 10,000 requests per hour and you’re counting each one, that’s 10,000 rows per hour for that single counter.

Histogram

A histogram records the distribution of values across buckets. The classic use case is request latency: instead of just knowing that you handled 10,000 requests, you know how many took under 50ms, how many took 50-200ms, and how many exceeded a second.

Histograms produce more rows per observation than counters because each observation contributes data across multiple buckets. Keep this in mind when estimating your rows/month needs.

For practical code examples of both types, the guide on instrumenting Cloudflare Workers walks through counters and histograms step by step.

Labels and Dimensions

Labels (sometimes called dimensions or tags) are key-value pairs attached to a metric. A counter called http_requests might have labels like method=GET, route=/api/users, and status=200.

Labels multiply your row count. If you have 5 routes, 3 HTTP methods, and 4 status codes, that’s potentially 60 unique label combinations per metric. Each combination with each data point is a separate row. This is the cardinality problem that haunts observability budgets everywhere, but because Distlang charges per row rather than per unique metric series, the math stays straightforward. You control your row count by controlling your label choices.

Ingestion and Client Terms

Ingestion

Ingestion is the process of receiving and storing your metric data points. When your application sends a batch of metrics to Distlang’s API, those data points are ingested, counted as rows, and become queryable in your dashboard.

Distlang bills by rows ingested, not by data volume in bytes. A row with five labels and a row with one label cost the same: one row each. This makes estimation simpler compared to byte-based billing where payload size varies with serialization format and label verbosity.

For details on payload structure and limits, see the guide on batching and payload format.

Flush and Buffering

Flushing is the act of sending buffered metric data from the client to the API. The Distlang JS client (@distlang/client) buffers data points in memory and sends them in batches. You trigger a flush explicitly, or it happens automatically based on your configuration.

Why this term matters so much: In serverless environments, your function might execute for only a few milliseconds. If the runtime shuts down before the client flushes, your metrics are lost. This is the single most common source of missing data in serverless observability.

The flush behavior configuration guide covers the exact settings and trade-offs. For a broader look at buffering strategies, check out buffering and flush strategies for short-lived handlers.

ctx.waitUntil() and after()

These are runtime-specific patterns for ensuring your metrics actually get sent before a serverless function terminates.

In Cloudflare Workers, ctx.waitUntil(promise) tells the runtime to keep the function alive until the promise resolves, even after the response has been sent to the client. You wrap your flush call in ctx.waitUntil() so metrics get transmitted without adding latency to the response. The Cloudflare Workers docs show the exact pattern.

In Vercel/Next.js, after() serves a similar purpose. It lets you schedule work (like flushing metrics) to run after the response is sent. The Vercel integration guide covers this.

API Token

An API token is a bearer token that authenticates your metric ingestion requests. Distlang uses a single long-lived token per account. You include it in the Authorization header of every request to the Metrics API.

The single-token model keeps things simple. There’s no multi-key management, no rotation schedules to worry about for side projects, and no per-environment token sprawl. For teams that need more detail, the API tokens reference covers the specifics.

Dashboard and Visualization Terms

Hosted Dashboard

Distlang auto-generates a hosted dashboard for each metric set at dash.distlang.com. You don’t need to install Grafana, configure Prometheus, or set up any visualization tooling. Send metrics, and the dashboard appears.

This is a core part of why comparing Distlang plan features is simpler than comparing legacy stacks. The dashboard isn’t an add-on or a premium feature. It’s included on every plan, including Free.

Metric Set Dashboard

Each metric set gets its own dedicated dashboard page. If you have three metric sets (say, auth-service, api-gateway, and billing), you’ll see three separate dashboards, each showing only the counters and histograms relevant to that set.

This automatic organization means you don’t start with a blank canvas. Your dashboards are structured from the moment data arrives.

Pricing Model Concepts

Understanding these concepts gives you the vocabulary to compare Distlang plan features against any other tool in the market.

Value Metric

A value metric is the unit a SaaS product charges for that correlates with the value customers receive. For Distlang, it’s rows per month. For a CDN, it might be bandwidth. For a traditional APM tool, it’s often hosts.

The choice of value metric matters enormously. 82% of above-average-growth SaaS companies have identified and implemented value metrics specific to their product’s core value proposition. Rows/month works well for a metrics service because it scales directly with how much observability data you’re generating.

Rows vs. Hosts vs. GB

Traditional observability vendors use different billing units. Per-host pricing charges for each server, container, or VM running an agent. Per-GB pricing charges for data volume. Per-custom-metric pricing charges for each unique metric name and label combination.

Each model has pathologies. Per-host pricing doesn’t map cleanly to serverless because there are no persistent hosts. Per-GB pricing penalizes verbose logging. Per-custom-metric pricing creates anxiety about adding labels.

Distlang’s row-based model avoids these traps. One data point equals one row, regardless of where it came from or how big the payload is. When your serverless functions scale to zero, your row count drops to zero too.

Retention-Based Tiering

Most observability platforms differentiate their plans by gating features. The cheap plan might lack alerting. The mid-tier might limit dashboard count. The expensive plan unlocks custom queries.

Distlang takes a different approach: all plans share the same features (unlimited metric sets, AI suggestions, hosted dashboards). The only things that change are volume (rows/month) and retention (how long data is queryable). This is retention-based tiering rather than feature-based tiering.

Research supports this structure. A study of 100+ SaaS companies found that simplified pricing with 3 to 4 tiers outperformed more complex structures with 5+ options. Distlang’s four tiers land right in that sweet spot.

The Observability Cost Crisis

This glossary exists in a broader context. More than half of engineering leaders allocate over 25% of their observability budget to a single platform, yet only 13% say they are very satisfied with the cost-to-value ratio. Nearly 80% of teams are filtering, archiving, or offloading logs to control costs.

When you compare Distlang plan features, you’re looking at a pricing model designed specifically to avoid the bill shock that plagues the industry. No host counting, no cardinality penalties, no surprise charges for custom metrics.

Explore Distlang Metrics plans to see the pricing structure firsthand.

Serverless-Native Metrics Collection

Because Distlang Metrics is built for serverless and edge runtimes, a few concepts are worth calling out specifically.

Traditional monitoring tools rely on agents, daemons, or sidecars running alongside your application. In serverless environments like Cloudflare Workers or Vercel Edge Functions, you can’t install agents. There’s no long-running process to host them.

Distlang’s approach is API-first. Your application code sends metrics directly via HTTP or the JS client. No agents, no pipelines, no infrastructure to maintain. This maps perfectly to the ephemeral nature of serverless: the distributed, event-driven nature of serverless functions makes traditional monitoring tools less effective.

For a comprehensive guide on getting started, the application instrumentation guide for Cloudflare and Vercel covers both platforms in detail.

Which Plan Fits Your Use Case?

Now that you understand every term, here’s how to apply that knowledge when you compare Distlang plan features for your specific situation.

Free ($0/mo, 500K rows, 7d retention): Perfect for side projects, hackathons, prototypes, and learning. You get 500K rows, which is plenty for a low-traffic app with a handful of metrics. Seven-day retention gives you enough lookback to debug recent issues.

Launch ($5/mo, 1.5M rows, 7d retention): Built for early-stage apps shipping to production. The 3x row increase over Free handles moderate traffic. Retention stays at 7 days, so this plan suits teams focused on real-time monitoring rather than historical analysis.

Hobby ($19/mo, 5M rows, 14d retention): The jump to 14-day retention is the key differentiator. If you need to compare metrics week-over-week (did last Tuesday’s deploy improve latency compared to the week before?), this is the plan. Five million rows supports a growing app with multiple instrumented services.

Growth ($79/mo, 20M rows, 30d retention): Monthly trend analysis, capacity planning, and sprint retrospectives all benefit from 30-day retention. Twenty million rows handles production applications with rich instrumentation across multiple services.

Ready to start? The metrics quickstart guide takes you from zero to your first dashboard in minutes.

FAQ

How do I estimate my rows/month usage?

Count the number of metrics you plan to track, multiply by the number of unique label combinations each metric will have, then multiply by how many data points per second you expect. A counter with 10 label combinations hit once per second generates about 864,000 rows per day (10 x 1 x 86,400 seconds). Start with the Free plan and watch your actual consumption before upgrading.

Can I switch plans at any time?

The plan structure is straightforward: Free, Launch, Hobby, and Growth. You can upgrade when your row consumption or retention needs change. Starting on a lower tier and moving up as your application grows is a common and sensible approach.

What happens if I exceed my rows/month limit?

The plan limits define how many rows you can ingest per month. Check the specific terms at signup for overage handling. Monitoring your row count in the dashboard helps you stay within your plan’s allocation.

Do all plans really include unlimited metric sets?

Yes. There is no cap on metric sets on any plan, including Free. You can create as many logical groupings of metrics as your architecture requires without any per-set charge.

Is there a difference in AI suggestion quality across plans?

No. AI suggestions for chart titles and descriptions are identical across all four tiers. There is no premium AI tier or reduced functionality on the Free plan.

Why does Distlang use rows instead of hosts or GB for billing?

Rows correlate directly with how much observability data you generate, regardless of where it runs. Per-host pricing fails in serverless contexts because there are no persistent hosts. Per-GB pricing penalizes verbose payloads. Rows are a simpler, more predictable unit, especially for serverless and edge workloads.

How does Distlang’s pricing compare to traditional APM tools?

Traditional APM tools often bill across multiple axes simultaneously (hosts, custom metrics, data volume, retention). Infrastructure monitoring alone can cost $15-18 per host per month, with APM adding another $31 per host, plus custom metric charges on top. Distlang’s single-axis billing (rows/month) with a fixed monthly price eliminates this complexity.

What’s the fastest way to get started with Distlang Metrics?

Sign up for the Free plan, grab your API token, and follow the developer onboarding checklist. You can be sending metrics and viewing dashboards within minutes.