DEV Community: Moksh Gupta

API Docs Platforms in 2026: What Removing the Vendor Logo Actually Costs

Moksh Gupta — Sun, 27 Sep 2026 19:19:03 +0000

Most API teams stopped hand-writing their reference docs years ago. Point a tool at an OpenAPI file and it renders the endpoint list, the schemas and a try-it console for you, which is exactly why it's strange that Postman's 2025 State of the API Report (5,700+ respondents, published August 2025) still found 55% of API teams fighting inconsistent, outdated or missing documentation. The spec is accurate. The docs still aren't. I went through pricing pages for six platforms to see why, and wrote a longer version of the breakdown on DevToolLab if you want every screenshot and the full per-tool rundown.

The workflow every tool here assumes

Same report: 60% of teams version their APIs, 57% keep specs in Git, and 41% now use AI somewhere in the docs pipeline (enough that Postman folded a generator called Fern into its own product). None of that changes what has to happen next - a spec still needs a tool to turn it into a browsable site with search, versioning, and usually a domain that doesn't say the vendor's name on it.

The gate that's easy to miss

Every platform below gives you a custom domain cheaply or free. What's gated separately, and priced very differently, is removing the vendor's own branding entirely.

Platform	Custom domain from	Branding removal
Mintlify	$0/month	Enterprise only, custom price
ReadMe	$0/month	Enterprise only, custom price
Stoplight	$113/month (annual)	$362/month (annual) tier
Redocly	$10/seat/month	not gated separately
Scalar	$0/month	not gated separately
Swagger UI	self-hosted	no vendor mark to begin with

Stoplight is the most upfront about it: Basic and Startup get domains and theming, but "Remove Stoplight branding" doesn't show up until Pro Team at $362/month billed annually. If "our logo, not theirs" is a hard requirement, that's the number to plan around, not the entry-tier price everyone quotes.

Six platforms, six pricing models

Mintlify is the fastest to stand up: point it at a GitHub repo and an openapi.yaml, and you get API reference, search and an in-browser playground in minutes, no build step. It also runs an AI layer that flags pages drifting out of sync with the spec. Free Starter caps at 5 editor seats; Pro is $450/month with unlimited seats and 10,000 AI credits (then $0.01/credit).

ReadMe is a full docs CMS wrapped around the API reference, and its editor can push changes back into your source repo, not just read from it. The catch is one project per plan below Enterprise, so two APIs need two subscriptions. Pro is $250/month annual.

Stoplight, a SmartBear product since 2022, leans into the design side: a visual OpenAPI editor plus shared style guides across up to 20 teams on Pro Team. Free is one user, one project; extra editors cost $11-27/month on top of whichever tier you're on.

Redocly sells hosting and a catalog layer on top of Redoc, the open-source renderer that clears 1M npm downloads/week (MIT, v2.5.3, 25,927 GitHub stars). Pro is metered: $10/seat/month, capped at 100 pages before you need the next tier.

Scalar is the one that's genuinely self-hostable start to finish - MIT core, 16,197 stars, shipped a release as recently as September 25, 2026. Run the reference UI and API client free forever; pay only for hosting, SDK generation or their MCP server output. Free stops at 3 APIs; Business tops out at 25.

Swagger UI is still the baseline everyone else gets compared to: Apache 2.0, 29,026 stars, no account or seat count because there's no hosted product at all. It renders one spec into one page and leaves hosting to you. If you just want to paste a spec and look at it without deploying anything, DevToolLab's Swagger Viewer does that same job in the browser.

Picking without migrating twice

A few things worth checking before you commit:

Count specs, not headcount. Redocly and Scalar price on distinct APIs and page counts, not seats, so match your real spec count against their tier tables.
Decide on branding removal up front. If zero third-party logo is non-negotiable, price Mintlify/ReadMe Enterprise or Stoplight's $362 tier now, not after launch.
Try the free renderer first. Paste your spec into Swagger UI or Scalar's open core - if it looks fine, the paid tier is selling hosting and search, not the rendering itself.
Match sync direction to who edits docs. ReadMe's bi-directional editing solves "writer fixes a typo without a PR." Mintlify's drift detection solves "spec and page disagree." Different problems.

The original post has the full side-by-side table (model, cheapest paid tier, self-host status, license) and a use-case breakdown for five different team shapes, plus the sourcing for every GitHub star count and release date above.

Bottom line

Turning an OpenAPI file into a readable page has been free for years, through Swagger UI and now Scalar's open core. What the current crop of paid platforms sells is what happens around that page - AI drift detection, bi-directional editing, multi-team governance, and a domain with nobody else's logo on it. Check which of those your subscription actually includes before renewing.

References

Tracing Backends in 2026: Same Spans, Five Different Bills

Moksh Gupta — Fri, 25 Sep 2026 18:17:55 +0000

A checkout request that hits a load balancer, three services, Postgres, a queue and Stripe leaves four seconds of latency and no obvious culprit until you stitch the hops into one timeline. That's what distributed tracing is for, and I went looking for what it actually costs to store that timeline once you're past the free tier. I wrote up the full breakdown on DevToolLab, and the short version is that nobody prices tracing the same way, so a side-by-side comparison means nothing unless you know your span size first.

Nobody bills the same unit

Grafana Cloud and SigNoz charge per gigabyte of spans. Honeycomb and Dash0 charge per span. Datadog charges per host plus per million indexed spans. AWS splits between per-trace (classic X-Ray) and per-gigabyte (the newer CloudWatch Transaction Search). None of that is comparable until you know how big your spans are, so instead of trusting a vendor's example numbers I generated 50,000 of them.

Using the official OpenTelemetry JS SDK and its OTLP protobuf serializer, I built a checkout trace: an HTTP server span, three SQL queries, an inventory service call, a Stripe call, a queue publish, four internal spans, us-east-1 Kubernetes resource attributes attached. Batched in groups of 512 (the SDK default), the average span came out to 266 bytes as protobuf and 656 bytes as JSON. That's a lean number, before auto-instrumentation adds its usual pile of attributes, and it matters because none of the per-GB pricing pages say whether their gigabyte is measured before or after compression.

What a month actually costs

Feeding 266-byte spans into each vendor's public rate card at two volumes (50 million spans across 6 hosts, and 500 million spans across 24 hosts) produced this:

50M spans/mo, 6 hosts = 13.3 GB
  Grafana Cloud Traces            $19.00
  SigNoz Cloud                    $49.00
  Datadog APM                     $350.80
  Honeycomb Pro                   $150.00
  Dash0                           $30.00
  AWS X-Ray (classic)             $24.50
  CloudWatch Transaction Search   $4.66
  Self-hosted Tempo (S3 only)     $0.31

500M spans/mo, 24 hosts = 133.0 GB
  Grafana Cloud Traces            $56.35
  SigNoz Cloud                    $49.00
  Datadog APM                     $1913.20
  Honeycomb Pro                   not published
  Dash0                           $300.00
  AWS X-Ray (classic)             $249.50
  CloudWatch Transaction Search   $46.55
  Self-hosted Tempo (S3 only)     $3.06

That's a roughly 40x spread on the same 500 million spans: $1,913.20 on Datadog versus $46.55 on CloudWatch Transaction Search. Bump the span size to 1 KB and only the per-GB backends move - Grafana Cloud goes to $221.50, SigNoz to $150.00 - while Datadog, Dash0 and X-Ray hold steady, because they never cared about bytes in the first place. Small spans favor per-GB pricing; fat, attribute-heavy spans make per-span pricing look better by comparison. None of this counts self-hosting compute, extended retention or volume discounts, so treat it as a starting estimate, not a quote.

The backends, briefly

Jaeger is the CNCF project, and v2 rebuilt it on top of the OpenTelemetry Collector framework. You pick the storage backend (Elasticsearch, Cassandra, ClickHouse, Badger), which means you also own operating it. v1 reached end of life December 31, 2025.

Grafana Tempo needs only object storage, and that's why it's cheap: our 133 GB month costs $3.06 in S3 before compute. Version 3.0 replaced the ingester architecture and made TraceQL metrics generally available, but the new write path pulls Kafka into a self-hosted deployment. Grafana Cloud Traces gives you 50 GB free, then $19/month gets you 50 GB more.

SigNoz stores traces, logs and metrics together in ClickHouse and prices at a flat $0.30/GB with a $49 minimum, no host or seat fees. The ee/ directory sits under a separate license, so it's not purely MIT, and ClickHouse at scale is its own operational job.

Honeycomb counts every span, span event and span link as a billable event but doesn't charge extra for attributes, which the docs call "unlimited custom fields." That makes high-cardinality debugging genuinely cheap, but only the 50M-event, $150/month tier is public. Go past 500 million and you're negotiating.

Datadog APM bills per host ($31/month, annual) plus per indexed span past the bundled allotment. In our 24-host run, indexed spans alone were $809 of the $1,913 total. It's the best option if Datadog already owns your infra dashboards; it's the worst option if you're optimizing for a tracing line item in isolation.

Dash0 charges $0.06/M spans ingested plus $0.54/M stored, 30-day retention, no free tier. Sampling inside its own SignalControl filtering only charges the ingest rate, so dropping spans there is cheap - but a lean 266-byte span gets you nothing, since the price is per-span, not per-byte.

AWS X-Ray / CloudWatch Transaction Search is mid-migration: the classic X-Ray SDKs went into maintenance mode February 25, 2026, and the product URL now redirects to CloudWatch. Transaction Search bills $0.35/GB ingested plus $0.75/M spans indexed beyond a small free allotment, and it came out cheapest of every hosted option in both of our workloads.

The math side by side

Backend	Billing unit	Entry price	Retention
Jaeger	Your storage	$0	You decide
Grafana Tempo	Per GB (Cloud)	Free 50 GB, then $19/mo	30 days
SigNoz	Per GB	$49/mo minimum	15 days
Honeycomb	Per event	Free 20M, then $150/mo	60 days
Datadog APM	Per host + indexed span	$31/host/mo	15 days
Dash0	Per span	$0.60 per 1M kept	30 days
AWS X-Ray / CloudWatch	Per trace or per GB	100k traces free	30 days (classic)

Picking one without migrating twice

Instrument with OpenTelemetry regardless of backend - Jaeger v2 is built on the OTel Collector and even AWS is steering people off its own SDKs, so vendor lock-in now happens at the pricing layer, not the instrumentation layer. Before you sign anything, point a Collector at a file exporter for an hour of real production traffic and divide total bytes by span count; that single number tells you whether per-GB or per-span pricing wins. Do your tail sampling in the Collector, not in the vendor's ingestion pipeline, since Grafana Cloud and Dash0 both bill ingestion even for spans you're about to sample out. And keep a Collector between your apps and whichever backend you pick, so switching later is a config change, not a redeploy.

If you're a small team, Grafana Cloud's $19/month Pro tier covered our entire 50-million-span workload inside its included 50 GB. If you want to own your data outright, Tempo or Jaeger-on-ClickHouse both work, but budget engineering time, not just storage dollars. If you're already deep in Datadog, stay, but index selectively - that's where the real cost sits. If you're all-in on AWS, CloudWatch Transaction Search undercut everything else we tested at both volumes. I go into more of the decision framework, plus the actual pricing script you can run against your own numbers, in the full post.

If you're setting up the collector side of this, DevToolLab's OTel Config Generator builds the tail-sampling and dual-write YAML mentioned above, and the Protobuf Decoder is handy for reading a captured OTLP span payload without hunting down the .proto file.

References

Best Distributed Tracing Tools in 2026 - DevToolLab - the original post, including the full cost-modeling script
Jaeger
Grafana Tempo
SigNoz
Honeycomb
Datadog APM
Dash0
AWS X-Ray

I Planted 10 Fake API Keys in a Repo and Ran 4 Secret Scanners on It

Moksh Gupta — Thu, 24 Sep 2026 18:14:48 +0000

Once a credential lands in a pushed commit, removing the line fixes nothing. The key is in every clone and every CI cache, so the only real remedy is revoking it at the provider, and you can only revoke the keys a scanner actually reports.

That makes detection quality the whole game. So instead of comparing feature pages, I built a small test: a throwaway repository with ten fake credentials in real token formats, one of them committed and then deleted, and four open-source scanners pointed at its full history. The longer version, with per-tool screenshots and pricing detail, is on DevToolLab. This is the condensed pass.

Why this got worse in 2025

GitGuardian's State of Secrets Sprawl 2026 report, released March 17, 2026, counted 28.65 million new hardcoded secrets in public GitHub commits during 2025, up 34% on the year before. Two other numbers from that report stuck with me. Commits co-written with Claude Code leaked secrets at 3.2%, about double the 1.5% baseline for all public commits. And 64% of credentials that were valid in 2022 still worked when retested in January 2026. People find leaks and never rotate.

The tooling landscape moved too. Praetorian archived Nosey Parker (last release v0.24.0, May 2025), Yelp's detect-secrets has not shipped since May 2024, and the original Gitleaks author started a successor called Betterleaks in February 2026 after saying he no longer fully controls the Gitleaks repo and name.

The test setup

The repo has four commits. The first holds an AWS key pair, a Postgres URL with a password, a Slack webhook and a SendGrid key in source files. The second adds a .env with a Stripe live key and a GitHub token, plus an RSA private key. The third deletes the .env and the key file, which is the classic "I noticed and cleaned it up" commit. The fourth adds an .mcp.json with inline OpenAI and Anthropic keys, alongside decoys: lockfile hashes, a UUID, AWS's documented AKIAIOSFODNN7EXAMPLE and a your-api-key-here placeholder.

Validation was off everywhere, so no tool could lean on calling a provider API. These are the exact commands:

gitleaks git ./repo -f json -r out/gitleaks.json --no-banner
betterleaks git ./repo -f json -r out/betterleaks.json
trufflehog git file://./repo --json --no-update --no-verification > out/trufflehog.json
kingfisher scan ./repo --no-validate -f json -o out/kingfisher.json

I regenerated the repo with fresh random values five times and got the same result every run:

gitleaks     findings= 9  seeds found=9/10  noise=0  missed=[postgres]
betterleaks  findings= 9  seeds found=9/10  noise=0  missed=[awsSecret]
trufflehog   findings= 9  seeds found=10/10  noise=0  missed=[]
kingfisher   findings= 9  seeds found=9/10  noise=0  missed=[awsSecret]

Every scanner caught the secrets hiding in the deleted commit, and none flagged a decoy.

Real code is where the ranking changes

A seeded repo is the easy case. To see noise, I timed each tool over the full history of Express (6,425 commits) on an Apple M3 Pro. Every single finding there was a false positive:

Scanner	Median time	Findings on Express
Betterleaks 1.8.1	0.77 s	5 (test fixtures, an example login, a package version)
Kingfisher 2.7.0	0.91 s	0
Gitleaks 8.30.1	1.08 s	0
TruffleHog 3.97.9	2.70 s	1 (a URL with credentials in a code comment)

So the fastest tool was also the noisiest on real fixtures, and the slowest was the only one with a perfect seed score. Run two scanners on your own noisiest repo before you pick one.

The four open-source scanners, briefly

Gitleaks (MIT, v8.30.1, March 21, 2026) is the default everyone reaches for: one Go binary, 222 rules, zero noise here. It missed the Postgres connection string entirely and does not validate anything. The last release is six months old.

Betterleaks (MIT, v1.8.1, August 18, 2026) is a drop-in replacement for Gitleaks with 463 rules, backed by Aikido Security. It filters candidates with BPE token efficiency instead of plain entropy; the project claims 98.6% recall on CredData versus 70.4% for entropy, which is the author's number, not an independent one. Its generic-password rule is the noise source.

TruffleHog (AGPL-3.0, v3.97.9, September 24, 2026) found all ten. Its real selling point is verification: it classifies 800+ secret types and logs in to check whether each one is live, so --results=verified turns a pile of findings into a revocation list. Watch the AGPL if you plan to embed it in something you ship.

Kingfisher (Apache 2.0, v2.7.0, September 24, 2026) is MongoDB's Rust scanner. Version 2 uses the Betterleaks rule catalog plus Google's Veles detectors, which is why its seed results matched Betterleaks exactly. What sets it apart is what happens after detection: it validates, maps the blast radius of a leaked key across 43 providers and can revoke 34 credential types, all in the free release.

The paid options

GitHub Secret Protection has been sold on its own since April 1, 2025 at $19 per active committer per month. Its best feature is push protection: the push is rejected before the secret ever enters history. Public repos get it free, but the generic patterns that catch connection strings are paid only.

GitGuardian's free Starter plan covers up to 25 developers, which for that headcount beats the $5,700 a year GitHub would charge. Its CLI, ggshield, sends content to GitGuardian's API for detection, so it does not scan locally. The full side-by-side table, with license and price columns, is in the original comparison.

What I would actually do

Run TruffleHog with --results=verified over every repo you own, once. The count of live keys tells you whether this is cleanup or an incident.
Block at push time. On GitHub that is push protection; elsewhere, a Gitleaks or Betterleaks pre-commit hook plus a CI job nobody can skip.
Allowlist your test fixtures on day one, or the noise trains your team to ignore the alerts.
If you need to know what a leaked key could reach, Kingfisher's blast-radius mapping is the free way to find out.

For a quick check before pasting a config into an issue or a Slack thread, I built a browser-based secret scanner that runs locally and redacts what it finds, and a Shannon entropy calculator that shows why a random token trips these tools while a long config value does not.

References

Best Secret Scanning Tools in 2026, Tested - the original, with the full comparison table and persona verdicts
GitGuardian: The State of Secrets Sprawl 2026
Aikido: Betterleaks, the Gitleaks successor
GitHub Changelog: Introducing GitHub Secret Protection and GitHub Code Security
Gitleaks, Betterleaks, TruffleHog, Kingfisher

Log Management Pricing in 2026: Four Rate Cards, One 500 GB Workload

Moksh Gupta — Wed, 23 Sep 2026 19:33:24 +0000

Metrics roll up. Traces sample. Logs do neither, which is why they are the telemetry bill that keeps climbing in a quarter where nothing shipped. Add a service, add a retry storm, hire two more engineers who each want their own debug lines, and the invoice moves without traffic moving.

I priced 500 GB of monthly log ingest against four vendor rate cards as published on September 23, 2026. Cheapest was $43.50. Most expensive was $1,360.72. Same bytes.

This is the condensed version. The full breakdown on DevToolLab carries the per-vendor detail, including the three open source engines I only summarize here.

Where Teams Say They Actually Are

Grafana Labs ran its 4th Annual Observability Survey on March 18, 2026, with 1,363 responses from engineers, SREs and technology leaders in 76 countries.

The top concern for 2026 was not cost. Complexity and overhead took it at 38%, with signal-to-noise at 34% and cost third at 31%. SaaS is now at half of all respondents in some capacity, up from 43% the year before.

The number worth planning around is OpenTelemetry adoption for logs specifically: 48%, against 57% for metrics and 50% for traces. Broader context: 77% say open source or open standards matter to their strategy. An OTel collector sitting in front of your backend is what turns a backend swap into a config edit instead of a quarter of work.

The Arithmetic

You cannot compare these vendors on a per-GB number, because they do not meter the same object. Datadog bills ingestion by GB and indexing by million events, tiered on retention. Grafana Cloud splits one pipeline into three GB meters: Write, Process, Retain. Elastic and Better Stack separate ingestion from retained GB-months. A dollar figure per GB with no unit attached is marketing, not a price.

So here is one workload against four rate cards:

const GB = 500
const KB_PER_LINE = 1
const MEVENTS = (GB * 1024 ** 2) / KB_PER_LINE / 1e6   // 524.288M lines at 1 KB each

const plans = {
  'Datadog, standard 30d index': { ingest: GB * 0.10, index: MEVENTS * 2.50 },
  'Datadog, Flex Logs Starter':  { ingest: GB * 0.10, flex: MEVENTS * 0.60 },
  'Grafana Cloud Logs Pro':      { platform: 19, write: (GB - 50) * 0.400, process: (GB - 50) * 0.050 },
  'Elastic Serverless, Logs Essentials': { ingest: GB * 0.07, retain: GB * 0.017 },
}

const usd = (n) => '$' + n.toLocaleString('en-US', { minimumFractionDigits: 2, maximumFractionDigits: 2 })
const rows = Object.entries(plans).map(([name, meters]) => ({
  name,
  total: Object.values(meters).reduce((a, b) => a + b, 0),
  breakdown: Object.entries(meters).map(([k, v]) => `${k} ${usd(v)}`).join(' + '),
}))

for (const r of rows.sort((a, b) => a.total - b.total))
  console.log(usd(r.total).padStart(10), ' ', r.name.padEnd(36), r.breakdown)

const totals = rows.map((r) => r.total)
console.log(`\nspread: ${(Math.max(...totals) / Math.min(...totals)).toFixed(1)}x on ${MEVENTS}M log lines`)

Output:

    $43.50   Elastic Serverless, Logs Essentials  ingest $35.00 + retain $8.50
   $221.50   Grafana Cloud Logs Pro               platform $19.00 + write $180.00 + process $22.50
   $364.57   Datadog, Flex Logs Starter           ingest $50.00 + flex $314.57
 $1,360.72   Datadog, standard 30d index          ingest $50.00 + index $1,310.72

spread: 31.3x on 524.288M log lines

Read the Datadog row again. Ingesting 500 GB costs $50. Indexing it costs $1,310.72, which is 96% of the bill. Every conversation about a Datadog invoice is secretly a conversation about what you agreed not to index.

The assumption doing the most work here is 1 KB per line. If your logs are structured JSON averaging 2 KB, you have half as many events and roughly half that indexing charge. Measure yours before you trust anyone's model, including mine.

The Managed Three

Datadog is the reference price everyone else quotes against. Logging without Limits decouples ingestion from indexing on purpose, so sending everything and indexing a slice is the intended design rather than a workaround. Correlation is the actual product: logs next to APM traces and metrics in one pane, with Watchdog flagging error outliers unprompted. Flex Logs at $0.60 per million events against $2.50 for 30-day standard indexing is a real answer to archive-versus-search, and CloudPrem now covers keeping logs on your own infrastructure. The catch is predictability. Two meters in different units, index pricing that varies by retention tier, and regional ingest variation ($0.10 in the US, $0.12 in the EU) mean the bill moves when traffic shape changes, not just when volume does.

Better Stack sells the inverse: bundled plans with one predictable number, aimed directly at Datadog invoices. The "30x cheaper than Datadog" line is plausible against standard indexing, though not verifiable like for like. Packaging is the real strength, since logs, traces, metrics, uptime monitoring and incident response come together, and the free tier is a tier rather than a trial. It does not scale down in a log-only shape: plans bundle three signals at equal volume, so 300 GB of logs and almost no metrics still pays for metrics.

Elastic Cloud Serverless took the cheapest slot because Logs Essentials prices ingestion and retention separately and low. Search is the reason to be here. This is the lineage that made full-text log search ordinary, and if debugging means arbitrary substring queries over unstructured output, nothing below beats it. Serverless also deletes the cluster-sizing exercise. Simplicity ends above Essentials, where Complete moves ingest to $0.09 and retention to $0.019 and adds separate metrics meters. One note: the $95/month entry price that circulates in third-party comparison posts does not appear on Elastic's own pricing page.

The Self-Hosted Four

Grafana Loki is the architectural odd one out, and its docs say why without hedging: it does not index log contents, only a label set per stream. That is the entire cost story. Labels in the index, bulk in object storage at S3 prices. If Prometheus and Grafana are already running, LogQL reads like PromQL's sibling. What you give up is fast arbitrary full-text search, since a query that cannot be narrowed by label turns into a scan, and a badly chosen label set gives you either unusable cardinality or streams too coarse to be useful. AGPL-3.0, v3.7.8 on September 17, 2026, 25,217 stars.

OpenSearch is the Apache-2.0 route to an Elasticsearch-shaped stack, and if your objection to Elastic is the license rather than the technology, this is the destination. Being unsurprising is the feature: the query DSL, index lifecycle management and dashboards all behave the way an ELK veteran expects. 3.8.0 landed August 5, 2026. It does not escape the operational weight of an inverted index, and its own install docs are honest about that, wanting vm.max_map_count at 262144 or higher, half of system RAM for the Java heap, and swap disabled.

Graylog sits in between: pipelines, streams, role-based access control and multi-tenancy shipped as a platform on top of OpenSearch and MongoDB, rather than parts you assemble. It supplies the operations layer raw engines omit, which is why it shows up wherever who-can-see-which-logs is the binding requirement. One correction worth repeating, because it is widely misreported: Graylog is not open source under the OSI definition. It ships under Server Side Public License v1, which is not OSI-approved, and GitHub's license detection returns NOASSERTION rather than an SPDX identifier. If your policy allows only OSI-approved licenses, this does not clear it. 7.1.9 was tagged September 2, 2026.

VictoriaLogs is the newest credible option and competes on resource efficiency rather than feature count. It claims up to 30x less RAM and up to 15x less disk than Elasticsearch and Loki. Treat that as a vendor claim, because it appears in VictoriaLogs' own docs with named comparison targets but no workload definition and no methodology I could find. What is checkable is the shape: one zero-config Apache-2.0 binary the docs say runs on a Raspberry Pi with no flag tuning. What it lacks is ecosystem, meaning a thin plugin catalog, little community troubleshooting material, and a query language nobody on your team has used. v1.52.0 shipped July 16, 2026.

Side by Side

Tool	Metering model	Entry price	Self-host	License
Datadog Logs	Ingest GB + index per M events	$0.10/GB + $2.50/M events	CloudPrem	Proprietary
Better Stack	Bundled plan by volume	Free 3 GB, then $350/mo	No	Proprietary
Elastic Serverless	Ingest GB + retained GB-month	$0.07/GB	Yes, self-managed	Elastic License
Grafana Loki	Write + Process + Retain GB	$0 self-host, Cloud free 50 GB	Yes	AGPL-3.0
OpenSearch	Infrastructure only	$0	Yes	Apache-2.0
Graylog	Infrastructure only	$0 Open edition	Yes	SSPL v1
VictoriaLogs	Infrastructure only	$0	Yes	Apache-2.0

Full per-vendor pricing lines, including Better Stack's plan ladder and Grafana Cloud's three meters, are in the original article.

Five Checks Before You Commit

Measure your average log line. Pipe a day of production output through wc -c, divide by line count. Every per-event price above moves inversely with that one number, and most people guess it wrong by 2x.
Split what you search from what you keep. What share of your logs gets queried during an actual incident? Under a fifth, and an ingest-cheap, index-selective model wins. That ratio decides more of your bill than the vendor choice does.
Test the query you run at 2am, not a benchmark. If your reflex is grepping unstructured stack traces for a substring, Loki's label model fights you no matter how good the price looks.
Check the license before the trial, not after. SSPL and the Elastic License are not OSI-approved, and AGPL-3.0 stops some legal teams cold. Finding this out in week three of a migration is expensive.
Ship through OpenTelemetry whoever wins. A collector in front of the backend makes the next migration a config change.

Two things make step 1 and step 5 concrete: the Grok Pattern Tester builds the patterns that turn unstructured lines into the fields every backend here bills you to index, and the OTel Config Generator writes the Collector YAML.

Picking One

Already deep in Datadog for APM. Stay, and move everything you do not query into Flex Logs. On this workload that is $1,360.72 down to $364.57 a month, no migration required.

Kubernetes with Prometheus and Grafana already running. Loki. Self-hosted if you have platform capacity, Grafana Cloud if not, where the free 50 GB tier covers a small cluster outright.

Full-text search over unstructured logs is the requirement. OpenSearch self-hosted if you have the operations budget for it, Elastic Cloud Serverless if you would rather pay $0.07 per GB than tune a cluster.

Small team, one bill, no platform work. Better Stack. One number to defend beats four meters to model.

Access control is the hard requirement. Graylog, assuming SSPL survives legal review. If it does not and the hardware is modest, VictoriaLogs is the Apache-2.0 fallback.

Conclusion

Log tools did not get cheaper in 2026. The cost of full-text indexing got explicit enough to shop around, which is a different thing. Datadog's Flex tier, Elastic's serverless retention pricing and Loki's label-only index are three implementations of one argument: stop indexing what you will never search.

Before the next renewal, get one number. What percentage of the logs you paid to index last quarter did anyone actually query? If nobody in the room can answer, that silence is your negotiating position.

References

Best Log Management Tools in 2026: Costs - the original, longer article on DevToolLab
Datadog Log Management
Better Stack Logs
Elastic log monitoring
Grafana Loki
OpenSearch
Graylog
VictoriaLogs documentation

Stripe and Adyen Just Bought the Usage-Based Billing Market

Moksh Gupta — Tue, 22 Sep 2026 17:53:38 +0000

If your product charges for a stream of events instead of a flat seat price, tokens in and out, agent runs, GPU seconds, you need a meter that survives a customer disputing the invoice: dedupe the events, aggregate them into a period, price them against the contract. I went looking for who still builds that independently and found the market had consolidated hard in the last year. I wrote a longer version of this comparison on DevToolLab, with the full pricing script and a screenshot of every dashboard; this is the short version.

The Independent Shortlist Isn't Independent Anymore

In ten months, all three vendors most comparison posts point to got bought. Kong announced it was acquiring OpenMeter on September 3, 2025. Stripe closed its purchase of Metronome on January 14, 2026, for an undisclosed price that reporting puts near $1 billion. Adyen agreed to pay $335 million for Orb on June 11, 2026, closing July 1 and folding it in as an "indirect wholly owned subsidiary" under an incubator model. Orb's own homepage now reads "an adyen company."

A Metronome-run survey from January 2025 found 85% of 100 surveyed SaaS companies had already adopted usage-based pricing, so the timing tracks. Worth noting the survey came from a vendor selling the thing it measured, but the acquisitions back up the trend either way.

The Math: Percentage of Revenue vs a Fixed Bill

Only two platforms in this space publish a price without a sales call: Stripe Billing at 0.7% of billing volume, and Flexprice, whose top self-serve tier is $1,000 a month. Everything else routes to Contact Sales.

Run that 0.7% against a self-hosted budget and the crossover point is concrete. At $50,000 a month in billing volume, 0.7% is $350, cheaper than any engineer's time. But if running something like Lago or Kill Bill yourself costs $3,000 a month in infrastructure and attention, the percentage fee overtakes that around $429,000 a month in billing volume, roughly a $5.1M annual run rate. Below that line, pay the fee. Above it, the math flips toward self-hosting. The original post has the runnable script behind this table if you want to plug in your own volume and infra budget instead of these three examples.

Six Platforms, Verified This Month

Stripe Billing charges 0.7% of billing volume, pay as you go, with up to 100 million metering events a month included. Anything past basic metering, multidimensional rates, negotiated contracts, routes to a Contact Metronome button, since that is exactly where Metronome landed after the acquisition.

Orb, now under Adyen, is the pick for genuinely complicated pricing: hybrid plans, matrix rates, mid-period recomputation when a contract changes. Customers include Vercel, Replit, Supabase and LaunchDarkly, and ingestion is stress-tested to 250,000 events a second. There's no published price; it's billings plus events plus a platform fee, quote only.

Lago is the open-source option with the most AI-billing polish: AGPL-3.0, 10,593 GitHub stars, v1.53.0 shipped September 8, 2026. Free to self-host; Premium (prepaid credits, entitlements, customer portal) is quote-only, and AGPL is a hard no for some legal teams.

Flexprice is the rare open-source vendor with a real public price ladder: free up to 100,000 events a month, $500/month for 1 million events, $1,000/month for 5 million events and up to $1.2M in cumulative billing. AGPL-3.0, 6,201 stars, v2.1.31. Those ceilings are low for a real token-metered workload, and plans gate on cumulative rather than monthly billing, so once an account crosses a threshold it stays across it.

OpenMeter, an Apache-2.0 project now owned by Kong, is a metering layer rather than a full billing suite: 2,331 stars, still pre-1.0 at v1.0.0-beta.233. The managed path is now Kong Konnect.

Kill Bill is the oldest option here and argues hardest against paying a percentage forever: fixed cost, self-run, Apache-2.0, 5,753 stars, 15+ years in production and 100,000+ subscriptions claimed. It is also a Java platform with a plugin architecture, and the heaviest operational lift of the six.

Picking One Without Migrating Twice

Run the math on your own volume before reading another pricing page. Under roughly $200,000 a month in billing volume, Stripe's 0.7% usually beats the engineering cost of running your own meter. Above it, count events rather than revenue, since event volume is what actually breaks self-serve tiers. A product generating 40 million events a month is outside every self-serve plan here regardless of vendor.

If you already know you need open source, the license split matters more than the feature list: Lago and Flexprice are AGPL-3.0, OpenMeter and Kill Bill are Apache-2.0. And if you are leaning toward Orb, get the multi-PSP commitment from Adyen in writing before migrating. The incubator model is explicitly described as a first phase, not a permanent structure.

One practical note whichever you pick: idempotency keys are what stop a replayed usage event from being billed twice, and a UUID generator is a fast way to mint test ones while you build the ingestion path. And if you are trying to work out what a 0.7% revenue share actually leaves you per customer against a flat monthly fee, running the numbers through a margin calculator makes the comparison concrete before you commit to either model.

Conclusion

2026 changed ownership, not capability. Two payments companies and an API gateway company bought their way into metering inside ten months, and what is left independent is mostly open source: Lago, Flexprice, OpenMeter and Kill Bill, all usable, all with real tradeoffs. The question worth asking at renewal time is whether your billing cost is a percentage that keeps growing with your revenue, or a number you control.

References

Best Usage-Based Billing Platforms 2026, DevToolLab - the full price simulation script, six dashboard screenshots and the side-by-side license and pricing table
Stripe Billing pricing
Orb
Lago
Flexprice
OpenMeter
Kill Bill

What DAST Tools Actually Cost in 2026: ZAP, Nuclei, Burp, StackHawk, Detectify

Moksh Gupta — Mon, 21 Sep 2026 18:10:07 +0000

Static analysis can tell you a SQL query is built with string concatenation. It cannot tell you that staging is terminating TLS and forwarding plain HTTP to the app server, or that an admin route survived a refactor and is still reachable with no auth check in front of it. Catching that class of bug means throwing real requests at a running deployment, which is the whole point of dynamic application security testing (DAST).

I went through six DAST tools and priced them off their own current pages rather than trusting last year's numbers anyone else might be quoting. I wrote the full breakdown on DevToolLab with screenshots of every pricing page; this is the condensed version with the numbers that matter most.

The price spread is enormous

Burp Suite Professional: $499 per user for a one-year subscription. StackHawk's Wingman tier: $10 per user per month. ZAP, Nuclei and Wapiti: $0, licensed Apache-2.0, MIT and GPL-2.0 respectively. Detectify publishes a full ladder, but in euros, from a €0 starter tier up to €15,000/year for Enterprise. All of that was pulled straight from vendor pages on September 21, 2026.

One correction that keeps getting missed in roundups: ZAP is not an OWASP project anymore. ZAP's own blog carries a banner stating it's "now supported by Checkmarx and is not part of any foundation." If a post you're reading still calls it "OWASP ZAP," it's working from stale information.

On adoption, there's no clean industry survey for this category the way CNCF runs one for Kubernetes, so GitHub stars are the least-bad public signal available: Nuclei sits at 31,395, ZAP at 15,797, Nikto at 10,735, Wapiti at 1,864 (checked the same day). Nuclei is also the most actively committed-to of the four.

Doing the per-seat math

Per-seat pricing and flat platform fees cross over at a team size most comparisons skip entirely. Running the numbers with each vendor's published rate:

Tool                           1 dev     5 dev    20 dev    50 dev
------------------------------------------------------------------
Burp Suite Professional         $499    $2,495    $9,980   $24,950
StackHawk Wingman               $120      $600    $2,400    $6,000
ZAP / Nuclei / Wapiti             $0        $0        $0        $0

Burp runs about 4.2x StackHawk per seat, and a 20-developer team pays roughly $7,580/year more choosing Burp over StackHawk at list price. But the license total isn't the number that should drive the decision. A scanner that hands you 400 findings on a mid-sized Rails app, 380 of which are the same reflected parameter reported repeatedly, costs an engineer a full day of triage. That's the real reason free tools aren't automatically the cheap option; see the DevToolLab post for the full walkthrough of that tradeoff.

The tools, briefly

ZAP (Zed Attack Proxy) is the default free pick, Apache 2.0, version 2.17.0 (Dec 2025), still getting commits days before this was written. It runs as a proxy, a headless scanner, or a CI-driven daemon via its Automation Framework, and the add-on marketplace covers a lot of ground commercial tools charge for, including auth handling and OpenAPI import. The catch: default active scans are noisy against modern SPAs, and tuning it to a trustworthy signal is a real project, not an afternoon.

Nuclei isn't a crawler and shouldn't be compared to ZAP head-to-head. It's a template engine, MIT licensed, 31,395 stars, version 3.11.1 (Aug 2026): point it at a target with a YAML template describing a request and a matcher, and it tells you if the condition holds. That makes it the fastest way to sweep many hosts for one specific CVE the morning it drops, but it won't discover your app's forms or parameters on its own.

Wapiti is the readable black-box option, GPL-2.0, 1,864 stars, version 3.3.2 tagged Aug 2026 (its own site still lists 3.3.1 as current, so trust the release tag). It crawls a live app, collects inputs, and fuzzes them for SQL/XPath/LDAP injection, XSS, file disclosure, command execution, XXE and CRLF injection. No commercial support and a much smaller contributor base than ZAP is the tradeoff.

Burp Suite Professional is priced for a human tester, $499/user/year. Repeater, Intruder and the manual proxy workflow are the actual product; the automated scanner is good but not the reason people buy it. It's a desktop app for one person, not CI infrastructure - PortSwigger sells a separate, sales-quoted product for pipeline scanning.

StackHawk has pivoted hard into the AI-coding-agent workflow. Wingman is $10/user/month, unlimited apps, 50 agentic scans per user per month, after a 14-day trial. The pitch is the scanner runs beside Claude Code, Cursor or Copilot so findings surface while the developer still remembers the feature. The 50-scan cap is the thing to watch if your CI config is chatty.

Detectify is the rare vendor that publishes a real ladder: €0 (Starter, up to 5 users), €2,500 (Standard), €5,000 (Professional), €15,000 (Enterprise) - all annual platform fees, all in euros. It leans on a Crowdsource network of external researchers for detection modules rather than an in-house rule set alone. The platform fee is a floor: API and Apex scanning cost extra per target, and PCI ASV scanning is a separate €500/year.

Picking one without buying twice

Confirm you actually need DAST this quarter - if there's no SAST, no dependency scanning and no secrets detection yet, those find more per hour of setup on an unscanned codebase.
Run ZAP against staging before spending anything. It costs an afternoon and tells you your real finding volume - 12 findings and 900 findings are different buying decisions.
Price the triage time, not just the license. Estimate minutes per finding from step 2 and weigh that against $499/seat; for most teams, engineer time is the bigger line item.
Decide whether you need authenticated scanning - anonymous-only coverage misses most real business logic, and this is where free tools cost the most setup time.
Match the pricing unit to your shape: per-seat punishes large teams with few apps, per-application/platform fees punish small teams running many services.

If you're already carrying a DAST finding into remediation, a couple of DevToolLab's utilities save the rescan round-trip: the Security Headers Checker confirms a missing CSP or HSTS header without waiting on a full scan, and the SSL Certificate Checker rules out a TLS chain problem before you chase a false positive.

Bottom line

The real story this year is that the cheap commercial tier got genuinely cheap - StackHawk at $120/developer/year is close enough to free that self-hosting ZAP purely to dodge a bill is worth reconsidering against your actual triage hours. Before renewing anything, ask how many findings from last quarter's scans an engineer actually acted on. Under ten, and you're paying for scan volume nobody's using - the fix is better tuning, not a bigger plan.

References

Six API Gateways, Priced on the Same Month of Traffic

Moksh Gupta — Mon, 21 Sep 2026 03:22:25 +0000

Nobody sets out to adopt an API gateway. You add TLS termination, then a token check, then per-customer rate limits, and at some point the thing in front of your services has become a product decision you never made deliberately.

So I stopped reading feature matrices and priced one fixed workload against every vendor's published rates instead. The short version: 50 million requests a month lands anywhere between $63.50 and $430 depending purely on which billing model you picked, and half the products here will not tell you a price at all. I published the full comparison, including the per-gateway detail, as Best API Gateways in 2026 on DevToolLab. This is the condensed pass.

Everything below was read off each vendor's own pricing page or release feed on September 20, 2026.

Who Actually Runs One

Gateways are not a niche. CNCF and SlashData's State of Cloud Native Development report, published November 11, 2025, found API gateways to be the single most adopted cloud native technology among backend developers at 50 percent, with microservices behind them at 46 percent. The same report counted 15.6 million cloud native developers.

Repository attention lines up roughly with that. On September 20, 2026 Traefik sat at 64,904 GitHub stars, Kong at 44,157, Apache APISIX at 17,147, Tyk at 10,823, and KrakenD Community Edition at 2,684. Stars are not production traffic, but all five shipped a release in the preceding quarter, which is more than you can say for a lot of infrastructure.

Pricing One Month, Four Ways

Tier tables compare tiers. They do not compare bills. So here is a script that prices a single workload against published rates: 50 million requests, 3 KB responses, eight services, one control plane, us-east-1. It prices the vendor invoice only, which is why the self-hosted options read $0 and still cost you compute and an on-call rotation.

// price-gateways.mjs - rates from each vendor's pricing page, September 20, 2026
const reqs = Number(process.argv[2] ?? 50_000_000);
const M = reqs / 1_000_000;
const egressGB = (reqs * 3) / 1_000_000;
const services = 8, controlPlanes = 1;

// AWS: HTTP $1.00/M to 300M then $0.90/M; REST $3.50/M to 333M then $2.80/M; egress $0.09/GB
const awsHttp = Math.min(M, 300) * 1.0 + Math.max(0, M - 300) * 0.9 + egressGB * 0.09;
const awsRest = Math.min(M, 333) * 3.5 + Math.max(0, M - 333) * 2.8 + egressGB * 0.09;

// API7 Cloud: $2 per 1M calls + $250 per gateway group + $10 per service
const api7 = M * 2 + controlPlanes * 250 + services * 10;

// Kong Konnect Plus serverless: $25 per control plane; 2 APIs included,
// then $20/mo for the first 10 total APIs and $10/mo for each extra.
const billable = Math.max(0, services - 2);
const kong = controlPlanes * 25 + Math.min(billable, 10) * 20 + Math.max(0, billable - 10) * 10;

console.log(`${M}M requests/month, ${egressGB} GB egress`);
for (const [n, c] of [["AWS HTTP API", awsHttp], ["AWS REST API", awsRest],
                      ["API7 Cloud", api7], ["Kong Konnect Plus", kong]])
  console.log(n.padEnd(20), "$" + c.toFixed(2).padStart(8));

Run it at the baseline, then at ten times the traffic, and the ordering flips:

$ node price-gateways.mjs 50000000
AWS HTTP API         $   63.50
AWS REST API         $  188.50
API7 Cloud           $  430.00
Kong Konnect Plus    $  145.00

$ node price-gateways.mjs 500000000
AWS HTTP API         $  615.00
AWS REST API         $ 1768.10
API7 Cloud           $ 1330.00
Kong Konnect Plus    $  145.00

Kong Konnect starts out 2.3 times pricier than an AWS HTTP API and ends up under a quarter of it, because Konnect charges per control plane and per published API while AWS charges per request. Whether your invoice tracks your traffic or your org chart matters far more than the headline rate.

Kong Gateway

Built on NGINX and OpenResty, and the plugin catalog is the reason it keeps winning evaluations. It runs either against PostgreSQL or in DB-less mode, which Kong documents as running "without a database using only in-memory storage for entities" from a declarative YAML or JSON file. That second mode is what makes it workable in a GitOps pipeline.

The catch is that Konnect's bill follows environments and teams rather than load, so staging and preview control planes are line items. Apache 2.0, v3.9.3 as of June 17, 2026. Konnect starts at $25 a month per serverless control plane, $200 hybrid, $500 dedicated plus $0.15 per GB.

Traefik

Traefik Proxy is Go, and its pitch is that it writes its own config: label a container or apply an Ingress and the route appears, with Let's Encrypt handled for you. HTTP/2, HTTP/3, TCP, UDP and gRPC are all in the open source build, as are OpenTelemetry traces, metrics and logs.

What you cannot get is a number. Both Traefik Hub tiers swap the price for a "Get Pricing" button, and the WAF, distributed rate limiting and OIDC live behind the first of them. MIT, v3.7.13 as of September 4, 2026.

Apache APISIX

An Apache Software Foundation top-level project that its README describes as built "on top of NGINX and etcd." Using etcd rather than a relational database is the real differentiator: plugins and routes hot-reload across the fleet with nothing to restart and no database in the request path.

The bill for that is operational. You are now running a consensus store, and etcd is usually the first thing to wake you up. Its homepage advertises 100+ plugins, about 18,000 QPS per core and 0.2 ms added latency, all vendor-measured. Apache 2.0, 3.18.0 as of August 20, 2026, with commercial support via API7 at $2 per million calls plus $250 per gateway group and $10 per service monthly.

KrakenD

KrakenD describes itself as "a stateless, distributed, high-performance API Gateway," and it means the stateless part literally: one Go binary, one config file read at boot, no database, no config store. Nodes are immutable and rollbacks are just the previous artifact. API composition is the standout feature, fanning one client request across several backends and merging the response, which deletes an entire backend-for-frontend tier.

The tradeoff is that nothing changes at runtime, so every config edit ships as a deploy. Its own feature matrix marks 71 rows "Not included in Community," service-level rate limiting among them, though endpoint-level rate limiting ships in the free edition. Apache 2.0, Community Edition v2.13.11 as of September 8, 2026, Enterprise priced on request.

Tyk

Tyk has spent two years turning into a control plane for things that are not REST. Native GraphQL was the original hook, and it now ships distinct proxies for Kafka and async streams, MCP tools and registries, and LLM traffic with prompt and cost controls. If a gateway has to sit in front of an agent runtime as well as an API, nothing else here covers as much surface.

Read the license before you commit. The core is MPL 2.0 but the ee directory carries a separate commercial license, so the open source Tyk and the Tyk you trialled may differ. Prices are quoted on request and the free Cloud trial runs 48 hours. 10,823 stars, v5.14.0 as of July 7, 2026.

Amazon API Gateway

If your compute is already Lambda, this is the default and the integration work you skip is worth real money. HTTP APIs are the cheaper of its two REST-shaped products, and the newer Portals feature gives you an AWS-native developer portal without adding a vendor.

It never gets cheaper though. There is no flat tier to graduate onto, so the invoice is a straight line through your traffic graph, and REST APIs cost three and a half times HTTP APIs for largely overlapping features. HTTP APIs run $1.00 per million to 300 million then $0.90, REST APIs $3.50 per million to 333 million then $2.80, with $0.09 per GB egress and a 12-month free tier of a million calls a month.

Picking One Without Migrating Twice

Price your actual last month rather than a tier, because the crossover between metered and flat-rate billing depends entirely on your numbers. Decide whether config changes are allowed to be deploys, since KrakenD insists they are and Kong, APISIX and Tyk hand you an admin API instead. Count the stateful components you are signing up for: PostgreSQL for Kong in traditional mode, etcd for APISIX, nothing for KrakenD or open source Traefik.

Then check the paywall before you prototype, not after. Build the proof of concept on the free edition and confirm rate limiting, OIDC and the developer portal are in the tier you actually plan to buy. And get anything "quoted on request" in writing, renewal uplift included, while you still have leverage.

If you want the per-persona verdicts and the full side-by-side table, they are in the original article.

Two things worth having open while you test: the Rate Limit Header Analyzer for checking that the policy you configured is the one clients actually receive, and the CORS Header Generator for building the Access-Control-Allow-* set once at the edge instead of in every service behind it.

What Changed This Year

Gateways stopped being only about REST. Four of these six now market AI, MCP or LLM proxying, and both Traefik and APISIX sell an AI gateway as its own product. That is where the roadmaps are heading, and it is also where the license boundaries are being redrawn.

The question to ask at renewal is not which has more plugins. It is whether the bill scales with your traffic or with your team. Metered pricing punishes growth; per-control-plane pricing punishes having lots of environments. Model both against next year.

References

Your One Dependency Is Actually 67 Packages

Moksh Gupta — Sat, 19 Sep 2026 17:56:22 +0000

Nobody audits a lockfile. You pick a handful of libraries deliberately, and everything underneath them shows up because a resolver said so, gets refreshed by a bot, and is never looked at again. The question supply chain security answers is what is actually down there, and whether it arrived the way you think it did.

I put a number on the first half of that on September 19, 2026. A fresh project with exactly one dependency, express@5.1.0, produced a CycloneDX bill of materials containing 67 components. The same process against a production Next.js 15 app with 112 direct production dependencies returned 762 library components, so the tree is nearly seven times larger than the part anyone chose. The longer version of this writeup, with every version and price, is on DevToolLab.

Reproduce the 67 in Under a Minute

With Trivy 0.74.0 on your path, this is the whole thing:

mkdir sbom-demo && cd sbom-demo
npm init -y > /dev/null
npm install express@5.1.0 --package-lock-only --no-audit --no-fund
trivy fs --scanners vuln --format cyclonedx --output sbom.json package-lock.json

Count what it wrote:

import json
bom = json.load(open("sbom.json"))
print(f"CycloneDX spec : {bom['specVersion']}")
print(f"components     : {len(bom['components'])}")
print(f"vulnerabilities: {len(bom.get('vulnerabilities', []))}")

What came back on the day I ran it:

CycloneDX spec : 1.7
components     : 67
vulnerabilities: 0

Zero vulnerabilities is the part worth reading carefully. It describes today, not next month, because disclosure almost always lands long after installation. The reason to keep the inventory is so that "are we affected" takes minutes rather than a week of grepping.

Three Jobs, Not One

The phrase "supply chain security" bundles together three problems that need separate tools, and treating them as one is why these projects stall.

Inventory means producing an SBOM listing every component in a build. Provenance means signing artifacts and attesting how they were produced, so a consumer can check the binary really came from the source it names. Detection means finding known vulnerabilities in the inventory, and separately catching packages that are malicious rather than just stale.

A scanner says nothing about whether your pipeline was tampered with. A signature says nothing about whether the thing you signed is full of compromised code.

The Free Stack Covers All Three

For inventory, Syft and Trivy both emit SPDX and CycloneDX and both carry an Apache 2.0 license. Syft, from Anchore, hit v1.52.0 on September 17, 2026 with 9,581 GitHub stars and does only cataloging, which makes it the cleaner pipeline component. Trivy, from Aqua Security, hit v0.74.0 on August 14, 2026 with 37,980 stars and folds scanning, misconfiguration checks and secret detection into the same binary. One tool in CI or one tool per job, that is the whole decision.

For detection, Grype reached v0.119.0 on September 17, 2026 and reads a Syft SBOM directly. Google's OSV-Scanner reached v2.6.0 on September 14, 2026 and pulls from the OSV database, where records are keyed to exact affected version ranges per ecosystem instead of vendor CPE strings. That difference shows up as noticeably fewer false positives. Both are Apache 2.0, and running both is not unreasonable.

For provenance, Sigstore's Cosign reached v3.1.3 on August 6, 2026. Its useful trick is keyless signing: short-lived certificates bound to an OIDC identity such as a GitHub Actions workflow, with the signature written to a public transparency log, so there is no long-lived private key for anyone to lose.

One thing to check if you are reading older comparisons: SLSA v1.2 is the current approved specification as of September 2026, and v1.1 is marked Retired. It adds a Source Track alongside the Build Track, which most published roundups predate.

Finally, storage. OWASP's Dependency-Track reached 5.1.0 on August 27, 2026 and ingests a CycloneDX SBOM from every build, then re-evaluates what it already holds as new advisories land. A CI scan answers "is this build clean right now". Dependency-Track answers "which of the forty services we shipped last quarter ship this package", which is the question an incident actually starts with, and one a folder of SBOM files cannot answer.

What the Paid Tools Are Selling

Reachability analysis, malicious-package detection, hardened base images and a support contract. The original article breaks the pricing down properly, but the shape is this.

Snyk publishes per-seat pricing: Free at $0 per month, Team from $25 per month, and Ignite from $1,260 per year, all per contributing developer, with Enterprise quoted. Chainguard sells the opposite approach, shipping hardened images so you have fewer CVEs to triage rather than better triage. Up to five images are free, and its Catalog tier with 2,000-plus images starts at $19,000 for a team of 10, built in SLSA L3 infrastructure under a contractual CVE remediation SLA. Both checked on their own pricing pages on September 19, 2026.

Socket is the third approach, judging a package by what its code actually does rather than matching it to a CVE list, which is the only one of the three that flags a malicious release on day zero. I could not verify its current pricing: socket.dev returned HTTP 403 to every non-browser client I tried, so I have left the number out rather than guess at it.

Side by Side

Tool	Job	License	Version (Sep 19, 2026)	Cost
Syft	SBOM generation	Apache 2.0	v1.52.0	Free
Trivy	SBOM plus scanning	Apache 2.0	v0.74.0	Free
Grype	Vulnerability scanning	Apache 2.0	v0.119.0	Free
OSV-Scanner	Vulnerability scanning	Apache 2.0	v2.6.0	Free
Cosign	Signing and attestation	Apache 2.0	v3.1.3	Free
Dependency-Track	SBOM management	Apache 2.0	5.1.0	Free, self-hosted
Snyk	Scanning plus reachability	Commercial	n/a	$0 to $1,260/yr per developer
Chainguard	Hardened base images	Commercial	n/a	5 images free; Catalog from $19,000
Socket	Malicious package detection	Commercial	n/a	Not publicly verifiable

Where to Start

Run Trivy in CI. One binary, an SBOM and a vulnerability report, no purchase order. That is the honest answer for most teams, and if a customer is only asking for an SBOM then Syft alone finishes the job.

Add Dependency-Track once you are running more than a handful of services, because per-build scanning stops answering the question you will actually be asked. Add Cosign and publish provenance if other people consume what you ship. Look at behavioral analysis if malicious packages rather than outdated ones are what worry you, since CVE matching structurally cannot catch those. Price Chainguard against the hours your team currently spends patching base images, not against zero.

Two things worth having open while you do any of this: a SHA256 file checksum for confirming a release artifact matches the digest its project published, and npm package info for looking at maintainers and release history before a package becomes one more node in the tree.

Conclusion

Everything load-bearing here is free and actively maintained. Syft, Trivy, Grype, OSV-Scanner, Cosign and Dependency-Track are all Apache 2.0 and all shipped a release within about five weeks of September 19, 2026. Between them you get an inventory, a scan, a signature and a history.

Paid tools buy less noise, day-zero malicious detection, hardened images and someone to call. None of that is the first step. Generate one SBOM, look at how many packages you did not know you were shipping, and decide from that number.

References

9 Supply Chain Security Tools in 2026 - the original article, with the full pricing breakdown and methodology
SLSA specification v1.2 - current approved version, Build and Source tracks
Syft and Grype - Anchore
Trivy - Aqua Security
Cosign - Sigstore
OSV-Scanner - Google
Dependency-Track - OWASP

Your RAG Chunker Cuts a Sentence in Half 98% of the Time

Moksh Gupta — Sat, 19 Sep 2026 12:39:59 +0000

When retrieval in a RAG pipeline comes back with the wrong passage, the first suspect is almost always the embedding model. Swap text-embedding-3-small for something with a bigger benchmark number, re-index, measure again. That is usually the wrong knob. If the chunk you pulled back stops halfway through the sentence that contained the answer, the answer is not in your index at all, and no embedding model is going to reconstruct it.

Chunking gets decided once, in a constructor argument, and then nobody looks at it again. So I looked at it: four strategies, one document (RFC 9562, the UUID specification, 114,629 characters), a 1,000-character target, and one metric that chunking libraries do not report. Plain fixed-size splitting landed a boundary mid-sentence 98 percent of the time. Paragraph-aware splitting managed zero. The full write-up with the complete script is on DevToolLab.

Four Ways to Cut a Document

Fixed size slices every N characters. Trivial to write, perfectly uniform output, and it has no idea what the text says.

Fixed size with overlap does the same thing, then copies the tail of each chunk onto the head of the next one, betting that whatever got severed will survive intact in at least one of the pair.

Recursive works down a ladder of separators, paragraph break first, then newline, then sentence, then space, and only drops to the next rung when a piece is still too big. Most frameworks ship this as the default.

Paragraph aware treats a paragraph as atomic. It fills a chunk with whole paragraphs and opens a new one when the budget runs out.

The Metric Nobody Reports

Chunk size is not the interesting number. Boundary placement is. A cut that lands on a sentence terminator or a blank line costs you nothing, because both halves are still coherent units. A cut anywhere else takes one idea and turns it into two useless fragments.

So the measurement is: collect every legal boundary in the document up front, then ask each strategy how many of its cuts missed. The test corpus is an RFC because RFCs have real paragraph structure and a plain-text canonical form, which makes them easy to fetch and hard to argue with.

The scoring half is about ten lines of Node with no dependencies:

// Every position where a sentence or a paragraph legitimately ends.
const sentenceEnds = [...doc.matchAll(/[.!?]["')\]]?\s+(?=[A-Z0-9])/g)].map((m) => m.index + m[0].length)
const paragraphEnds = [...doc.matchAll(/\n\s*\n/g)].map((m) => m.index + m[0].length)
const SAFE = new Set([...sentenceEnds, ...paragraphEnds, 0, doc.length])

// A chunker returns [start, end] pairs. Every start after the first is a cut it chose.
const midSentence = (chunks) => chunks.slice(1).filter(([start]) => !SAFE.has(start)).length

And the strategy that scores zero is not complicated either, which is the uncomfortable part:

// Never split a paragraph. Pack whole paragraphs until the budget is gone.
const byParagraph = (text) => {
  const out = []
  let start = 0, cur = 0
  for (const end of [...paragraphEnds, text.length]) {
    if (end - start > SIZE && cur > start) { out.push([start, cur]); start = cur }
    cur = end
  }
  if (cur > start) out.push([start, cur])
  return out
}

The original article carries the whole runnable file, including the recursive splitter and the corpus cleanup that strips RFC page furniture.

What Came Back

Node 25.5.0, run September 14, 2026:

document: RFC 9562, 114,629 chars, 616 sentences
target chunk size: 1000 chars (overlap 200 where used)

strategy           chunks  avg size   mid-sentence   mid-para  total chars
------------------------------------------------------------------------------
fixed size            115       997      112 (98%)        112      114,629
fixed + overlap       144       995      142 (99%)        142      143,229
recursive             147       780       15 (10%)         15      114,629
paragraph aware       132       868         0 (0%)          0      114,629

112 bad cuts out of 114 is not a tail case you can ignore, it is what the strategy does on every document that is not pre-chopped into 1,000-character pieces.

The overlap row is the one worth staring at. It cuts mid-sentence at 99 percent, slightly worse than plain fixed size, because shifting the stride by 800 instead of 1,000 does nothing to align it with the prose. What overlap actually buys is a duplicate of the damaged region living inside the neighbor, and the bill for that shows up in the last column: 143,229 characters embedded instead of 114,629. That is 25 percent more vectors, 25 percent more storage, 25 percent more spend at every re-index, to paper over a boundary problem that recursive splitting removes for free.

Recursive drops the bad-cut rate to 10 percent and costs nothing but uniformity: 147 chunks averaging 780 characters against fixed size's tidy 115 at 997.

Where It Stops Being Free

Structure-aware splitting produces uneven chunks, and that is a real tradeoff rather than a rounding error. A 200-character chunk and a 900-character chunk do not carry comparable specificity once embedded, so cosine similarity between them is not quite apples to apples, and short chunks can punch above their weight in a ranked list. Recursive sits in the middle of that tension, which is a decent explanation for why it is everyone's default.

Paragraph-aware hitting exactly zero also depends on the corpus. RFC paragraphs happen to fit under a 1,000-character budget. Point it at a document with 3,000-character paragraphs and it either blows the budget or falls back to something else, so check your source before assuming the zero transfers.

Five Things to Do With This

Move off plain fixed size today. Recursive is the same single config line and removes roughly 90 percent of the damage. For prose, there is no case where fixed size is the better pick.
Go paragraph-aware on structured text. Specs, contracts, API docs, anything with genuine paragraph markup can reach zero mid-sentence cuts.
Treat overlap as a last resort, not a default. Here it added 25 percent to the embedding bill and improved nothing. It earns its keep only when the text has no usable separators at all, like untimed transcripts or raw OCR.
Score boundaries, not sizes. Every library will happily print its chunk length distribution. None of them tell you how many ideas got bisected, and that is the number correlated with retrieval quality.
Budget in tokens, not characters. Roughly 250 English tokens fit in 1,000 characters, and far fewer in most other languages, so a character budget quietly shrinks your chunks the moment your corpus is not English.

Clean the Input First

Half the boundary damage in real pipelines comes from garbage the chunker was never designed to see. Markdown link syntax and heading markers eat budget without carrying meaning, so run documents through Markdown to Text before embedding. Zero-width and non-breaking characters from PDF and web scrapes are worse, because they survive every normalization step and sit invisibly inside what should be a clean sentence boundary; Invisible Character Remover strips them.

Conclusion

The chunking default in most RAG stacks severs a sentence at nearly every boundary it creates, and the standard remedy for that, overlap, charges a 25 percent embedding tax while leaving the cut rate untouched. Switching to recursive splitting is a one-line change that eliminates most of the problem, and on structured documents paragraph-aware eliminates all of it. Before you spend another sprint tuning the retriever or shopping for a better embedding model, run the boundary count on one of your own documents. The number is usually embarrassing.

References

RAG Chunking Strategies, Measured - the original article, with the complete script and full methodology
RFC 9562: Universally Unique IDentifiers - the test corpus
Best RAG Platforms and Tools - what runs the pipeline once chunking is settled
Best PDF Parsers for RAG - the ingestion step where structure is preserved or lost
How LLM Tokenization Actually Works - why characters and tokens are not interchangeable budgets

Your OpenRouter Model Slug Is a Pool, Not a Deployment

Moksh Gupta — Fri, 18 Sep 2026 19:00:37 +0000

Moving from a vendor SDK to OpenRouter reads like a trivial migration. The request shape stays OpenAI-compatible, you change a base URL, and suddenly one key reaches hundreds of models. What the diff does not tell you is that the string you put in model does not identify a machine. It identifies a pool of them.

I pulled numbers off OpenRouter's public API on September 14, 2026 to see how wide that pool gets. For deepseek/deepseek-v4-flash-0731, 28 separate providers answer to that one slug, and their input pricing runs from $0.04 to $0.44 per million tokens, a spread of 11x. For qwen/qwen3.8-27b, 15 providers disagree about the context window by 15.3x: one advertises 66k, another claims 1,000k. The longer write-up with the full methodology is on DevToolLab.

The Default Is Availability, Not Reproducibility

OpenRouter does not hide this. Their provider routing docs state that requests are load balanced across the top providers by default, specifically to maximize uptime.

For uptime that is the right call. For anything you need to reproduce, it is a trap. Fire the same request twice sixty seconds apart and you can hit two different machines running two different quantizations with two different context ceilings at two different prices, with an identical payload and no code change between them. Open-weight models make this worse, because anyone with GPUs can join the pool.

Measuring It Yourself

The /endpoints route is unauthenticated, so you can check any model without a key. Node 18 or later, nothing to install.

// or-variance.mjs - Node 18+, no deps, no API key needed
const MODELS = [
  "z-ai/glm-5.2", "deepseek/deepseek-v4-flash-0731", "z-ai/glm-5.3",
  "deepseek/deepseek-v4-pro-0813", "moonshotai/kimi-k2.6", "qwen/qwen3.8-27b",
]

const perM = (v) => Number(v) * 1_000_000
const ratio = (a, b) => (b === 0 ? Infinity : a / b)

for (const id of MODELS) {
  const r = await fetch(`https://openrouter.ai/api/v1/models/${id}/endpoints`, { signal: AbortSignal.timeout(25000) })
  if (!r.ok) { console.error(`skip ${id}: HTTP ${r.status}`); continue }
  const eps = (await r.json()).data.endpoints ?? []
  if (!eps.length) continue

  const inPrices = eps.map((e) => perM(e.pricing?.prompt ?? 0)).filter((n) => n > 0)
  const ctx = eps.map((e) => e.context_length ?? 0).filter(Boolean)
  const quants = [...new Set(eps.map((e) => e.quantization ?? "undeclared"))]
  const tools = eps.filter((e) => (e.supported_parameters ?? []).includes("tools")).length

  console.log(
    `${id.padEnd(32)} ${String(eps.length).padStart(3)} providers  ` +
      `$${Math.min(...inPrices).toFixed(2)}-${Math.max(...inPrices).toFixed(2)}/M ` +
      `(${ratio(Math.max(...inPrices), Math.min(...inPrices)).toFixed(1)}x)  ` +
      `ctx ${(Math.min(...ctx) / 1000).toFixed(0)}k-${(Math.max(...ctx) / 1000).toFixed(0)}k  ` +
      `tools ${tools}/${eps.length}  quant: ${quants.join(", ")}`,
  )
}

What came back that day:

model                            prov         in $/M  spread           context  spread
--------------------------------------------------------------------------------------------
z-ai/glm-5.2                       33      0.49-2.31    4.7x        203k-1049k    5.2x
deepseek/deepseek-v4-flash-0731    28      0.04-0.44   11.0x        262k-1311k    5.0x
z-ai/glm-5.3                       27      0.92-2.10    2.3x        262k-1311k    5.0x
deepseek/deepseek-v4-pro-0813      21      0.66-1.65    2.5x       1000k-1049k    1.0x
moonshotai/kimi-k2.6               21      0.58-1.09    1.9x         256k-262k    1.0x
qwen/qwen3.8-27b                   15      0.15-0.45    3.0x         66k-1000k   15.3x

Which Spreads Actually Hurt

Price is the one that looks scariest and matters least. OpenRouter sorts on price by default, so ordinary traffic settles near the floor of that 11x range. You feel it when you pin a provider for quality reasons and find out what quality costs.

Context is where things break without telling you. If one host behind qwen/qwen3.8-27b caps at 66k and another accepts 1,000k, then a 200k-token prompt is a coin flip. Worse, the failure surfaces as an intermittent API error, so you go hunting for a bug in your retry logic instead of your routing config.

Quantization is declared rather than verified. Every model I checked had at least one provider reporting unknown, and moonshotai/kimi-k2.6 alone spanned int4, fp4, fp8, bf16 and unknown. A 4-bit build and a bf16 build are not the same model in any sense that matters to output quality, but they share a slug.

Capability varies too. On qwen/qwen3.8-27b, 14 of 15 providers advertised tool support. The fifteenth did not. Route purely on price, land on that one, and your function calling breaks for reasons no amount of reading your own code will explain.

The Part the Metadata Cannot Tell You

Everything above is self-reported. Two providers can publish identical specs and still behave differently under real traffic, and no API call will surface that.

Mohamed Moustafa's write-up, So you want to use OpenRouter, is the best public account of this failure mode. Running a production assistant across OpenRouter, he found benchmark gaps between providers on one slug, hosts that accept image inputs then ignore them, reasoning-effort parameters silently dropped, tool calls returned as raw text instead of structured output, and 200 responses carrying empty bodies. Declared precision turns out to be a weak signal for actual quality. The DevToolLab version of this post goes further into how his findings line up with the metadata.

Pinning, in Six Fields

The controls exist. They are just off by default. The provider object accepts:

Field	Default	Effect
`order`	-	Provider slugs to try in sequence
`only`	-	Restrict routing to these providers
`ignore`	-	Exclude these providers
`allow_fallbacks`	`true`	Permit fallback when the primary is down
`require_parameters`	`false`	Route only to providers honoring every parameter sent
`quantizations`	-	Limit to declared levels such as `fp8` or `bf16`
`data_collection`	`"allow"`	Exclude providers that may retain your data
`zdr`	-	Restrict to zero data retention endpoints
`max_price`	-	Cap price per million tokens

In practice:

Turn on require_parameters: true before anything else. One boolean, and it eliminates every bug where a host quietly discards your tools or reasoning settings.
Reach for only when you mean only. order still falls through to providers you did not list. A genuine hard pin is order plus allow_fallbacks: false.
Never pin to a single provider in production. Their incident becomes your incident. Use a tested shortlist instead.
Filter quantizations on anything quality-sensitive. Dropping unknown alone eliminates the deployments you have the least information about.
Set data_collection: "deny" or zdr: true now rather than during a compliance review. Both are one field today and a migration later.
Log the serving provider on every response. OpenRouter hands it back, and without it a quality regression has no owner.

A couple of things make the debugging cheaper. JSON Diff will show you exactly which fields differ between two providers answering the same prompt, and the LLM Token Cost Calculator converts an abstract 11x spread into the monthly bill that decides whether pinning is affordable.

When the Default Is Fine

This is not a case against OpenRouter. If you are comparing six models in an afternoon, or building something for yourself, or deciding what to standardize on, one key across hundreds of models is genuinely excellent and price-first routing is what you want.

The failure is a timing problem rather than a technical one. Something you spiked in a week turns into something customers depend on, and nobody goes back to the routing block. Treat it like any other dependency once real traffic arrives. Known providers, explicit capability requirements, enough logging to name the one that regressed.

Wrapping Up

A model slug on OpenRouter is a pool. For a widely hosted open-weight model, that pool reached 33 providers in my sample, with pricing varying 11x, context ceilings varying 15x, and five competing claims about quantization. That is exactly what you want for uptime and exactly what you do not want for reproducible output, and about six fields separate the two postures. Point the script at whatever you actually ship before you decide which one you are in.

References

Opsgenie Dies April 2027. Here Is What to Move To

Moksh Gupta — Fri, 18 Sep 2026 19:00:31 +0000

On-call tooling is the least glamorous thing in an observability stack and the only part that has to work while everything else is broken. It survives people quitting, phones on silent, and escalation chains nobody rehearses until 3am on a holiday weekend.

Two of the defaults for that job died within a year of each other. Atlassian's migration page states that Opsgenie runs "without interruption until April 5th, 2027," and after that "the product will no longer be accessible; any customer data in Opsgenie that has not been moved will also be deleted." Grafana OnCall OSS, the answer everyone gave when the reply was "self-host it," went into maintenance mode in March 2025 and was archived in March 2026. I put the full comparison, with per-vendor screenshots, on DevToolLab.

This Is a Deletion Date, Not a Deprecation

Worth being precise about the difference, because it changes your timeline. Plenty of products get "deprecated" and then quietly run for another five years. This is not that. Atlassian published a calendar date and attached data destruction to it. Rotations, escalation policies, integrations and incident history all have to be somewhere else by April 5, 2027 or they stop existing.

Atlassian's own destination is Jira Service Management, which absorbed the alerting and on-call features, and they ship automated migration tooling into it.

The Free Self-Host Option Closed Too

Grafana OnCall OSS carried the self-hosted recommendation for years. Its docs now open with a caution notice: archived as of March 24, 2026, development continuing in Grafana Cloud IRM instead. The repository was relocated to grafana-cold-storage/oncall and GitHub flipped it read-only on June 5, 2026.

The last release still runs. Nobody is shipping patches for it, which for something holding your paging path is a different risk calculation than for a CLI tool.

Six Replacements, Priced

Every figure here came off the vendor's own pricing page, checked September 18, 2026. Annual rates are shown where the vendor publishes a discount.

Tool	Entry	Mid	Free tier	Open source
PagerDuty	$25 Professional	$49 Business	5 users	No
incident.io	$19 Team	$25 Pro	Basic, forever	No
Rootly	$20 Essentials	Enterprise on request	No	No
FireHydrant	$25 Pro, annual	Enterprise on request	10 responders	No
Jira Service Management	$20 per agent	$51.42 Premium	3 agents	No
Keep	Self-hosted, free	Cloud on request	All of it	MIT outside `ee/`

PagerDuty is the incumbent and charges accordingly: $25 per user monthly, $21 annually, with Business at $49 or $41. Its real product is the integration catalog, so if your alert sources are a mess it is the shortest path. The bill stings as soon as you are paying full seats for engineers who take the pager twice a year.

incident.io treats the Slack or Teams channel as the incident surface instead of a separate console. The Basic tier is genuinely free forever and covers single-team on-call and a status page. Team is $19 monthly or $15 annually, Pro is $25.

Rootly opens at $20 per user and markets an AI layer: similar-incident lookup, a scribe for meeting notes, in-incident chat help. Judge the scheduling and escalation primitives first, since those are the parts you are actually replacing.

FireHydrant is the one with a genuinely different pricing shape, and I think it is the most under-discussed option here.

It charges per responder, not per seat. If 25 people out of 200 engineers carry the pager, that gap against seat-based pricing is enormous. Its free tier covers 10 responders, which is the most generous starting point of any commercial option in the table.

Jira Service Management is the low-risk migration and the awkward one. Same vendor, first-party tooling, no export-reimport of history. It is also the vendor that just killed the product you are migrating off, and per-agent pricing is a different shape from what Opsgenie charged, so model the bill before committing.

Keep is the surviving open-source answer: MIT licensed outside its ee/ directory, 12,334 stars, v0.54.3 shipped September 9, 2026, commits landing continuously. It bills itself as AIOps and alert management rather than an on-call scheduler, so it is strong at correlating and deduplicating alerts across sources and thinner if what you want is a rotation calendar with reliable phone delivery. LinkedIn's oncall also still exists, BSD-2-Clause and roughly 1,257 stars, but its last commit was August 2025.

The Costs That Are Not on the Pricing Page

Three things decide the real number, and the original post works through each in more detail.

Seat versus responder pricing can differ by a multiple on identical headcount, so count who can actually be paged before you compare quotes. Voice and international SMS are metered almost everywhere and they are the feature that has to work; PagerDuty's free tier, for instance, includes 100 international phone and SMS notifications monthly, which a US-only rotation will never notice and a distributed one will hit fast.

The one that eats the schedule is integration rebuild. Rotations and escalation policies port fine. The long tail of systems pointed at your current webhook endpoints does not, and that inventory is always longer than anyone guesses. A webhook signature verifier is worth having open while you repoint them, and an uptime SLA calculator helps settle which alerts deserve a phone call at all.

Picking One

Already committed to Atlassian: Jira Service Management, with the bill modeled first. Running incidents in Slack: incident.io, cheapest commercial entry and the Slack model is the product. Small pager rotation inside a big org: FireHydrant, on responder pricing alone. Messy alert sources and no appetite for risk: PagerDuty. Set on self-hosting: Keep, with engineering time budgeted, because you are shaping an alert platform into an on-call tool rather than unboxing one.

Wrapping Up

A deletion date with data destruction attached is not a roadmap item to revisit next quarter. The commercial field sits between $19 and $25 at entry, FireHydrant has the free tier worth taking seriously, and Keep is the one maintained open-source option left standing.

Plan against the calendar instead of the feature matrix: inventory what pages you today, count your real responders, and run a live rotation on a trial while you still have the option to change your mind.

References

The Cheapest Sub-Minute Uptime Monitor in 2026 Is Free

Moksh Gupta — Thu, 17 Sep 2026 18:46:10 +0000

Uptime monitors all look interchangeable on a pricing page. They are not, and the thing that separates them is buried in the fine print: how often the service checks, how many endpoints it watches before billing starts, and whether it can page a human at 3 AM. Those three move independently, and the free tiers are where they diverge hardest.

I priced seven of them off their own pages on September 17, 2026 and ran the arithmetic. One result was worth the exercise on its own: if you need a mean detection time under a minute for 10 endpoints, the cheapest option is a free plan, not a paid one. Checkly's Hobby tier does it for $0. UptimeRobot hands you five times as many monitors free, but checks a fifth as often, so it cannot clear the same bar.

The longer version of this lives on DevToolLab with the full per-vendor breakdown. This is the compressed argument.

The Numbers Side by Side

Tool	Free tier	Free interval	Entry paid plan	Fastest interval
UptimeRobot	50 monitors	5 minutes	$9/mo, 10 monitors	15 seconds
Better Stack	10 monitors, 10 heartbeats	3 minutes	$25/mo per extra 50	30 seconds
Checkly	10 monitors	2 minutes	$24/mo, 50 monitors	30 seconds
Cronitor	5 monitors	5 minutes	$2/mo per monitor	30 seconds
Uptime Kuma	unlimited, self-hosted	configurable	none, MIT	configurable
Gatus	unlimited, self-hosted	configurable	hosted plan exists	configurable
Upptime	unlimited, GitHub Actions	5 minutes	none, MIT	5 minutes

Detection Time Is Half the Check Interval

Here is the piece most comparisons skip. A failure does not politely wait for your monitor. It lands at a random moment between two checks, so on average you wait half the interval before anything even looks. That is your floor, before alerting adds its own lag.

Thirty lines of Node turns that into a ranking. No dependencies, runs on Node 18 or newer.

// Plan data read from each vendor's pricing page on September 17, 2026.
const PLANS = [
  ["UptimeRobot Free",    0,  50, 300],
  ["UptimeRobot Solo",    9,  10,  60],
  ["UptimeRobot Team",   35, 100,  30],
  ["UptimeRobot Scale",  65, 200,  15],
  ["Better Stack Free",   0,  10, 180],
  ["Checkly Hobby",       0,  10, 120],
  ["Checkly Starter",    24,  50,  60],
  ["Checkly Team",       64,  75,  30],
  ["Cronitor Hacker",     0,   5, 300],
]

const NEED = 10            // endpoints you actually have
const TARGET_DETECT = 60   // acceptable mean seconds to detection

const rows = PLANS.map(([name, usd, monitors, interval]) => ({
  name, usd, monitors, interval,
  meanDetect: interval / 2,
  perMonitor: usd === 0 ? 0 : usd / monitors,
  fits: monitors >= NEED,
}))

const ok = rows
  .filter((r) => r.fits && r.meanDetect <= TARGET_DETECT)
  .sort((a, b) => a.usd - b.usd)

console.log(ok.length ? `${ok[0].name} at $${ok[0].usd}/mo` : "nothing qualifies")
// -> Checkly Hobby at $0/mo

The per-monitor column is what reorders the market. UptimeRobot Scale looks expensive at $65 a month until you divide by 200 monitors and get $0.33 each, the cheapest paid slot anywhere in the table. Checkly Team costs a dollar less in absolute terms and works out at $0.85, because it bundles 75 monitors instead of 200. Sorting by sticker price gets this exactly backwards, which is covered in more depth in the original post.

The Hosted Four

UptimeRobot has the most generous free tier here: 50 monitors on a 5-minute interval, no card required, covering HTTP, port and ping. Paid tiers as of September 17, 2026 run $9 (Solo, 60-second checks), $35 (Team, 30-second, 100 monitors) and $65 (Scale, 15-second, 200 monitors) on annual billing. The free tier's catch is arithmetic: 5-minute checks mean roughly 150 seconds pass on average before a failure is noticed. Acceptable for a brochure site, not for checkout.

Better Stack is the one to pick when uptime and on-call should be a single workflow rather than two subscriptions. Its own page advertises 10 monitors, 10 heartbeats and a status page at 3-minute checks for nothing. After that the pricing is modular: another 50 monitors costs $25 a month, or $21 billed yearly.

Checkly treats monitoring as code, so checks live in Git beside the Playwright tests they reuse. Annual pricing is $0 for Hobby (10 monitors at 2-minute frequency), $24 for Starter (50 monitors at 1 minute) and $64 for Team (75 monitors at 30 seconds across 22 locations). Watch the overages, which is where the bill surprises people: browser check runs past your allowance bill at $6.50 per 1,000 on Starter.

Cronitor came from cron job monitoring and still handles that better than the generalists. Hacker is free forever with 5 monitors; Business charges $2 per monitor per month plus $5 per user with no base fee, reaching 30-second checks. Per-monitor billing is excellent at 10 monitors and brutal at 200. If your real question is whether last night's backup ran, this is the right shape.

The Open-Source Three

Uptime Kuma is the default self-hosted answer and dwarfs everything else in this category: MIT licensed, 91,453 GitHub stars, version 2.5.5 shipped September 16, 2026 with commits landing the next day. One docker run gets you HTTP, TCP, ping, DNS and keyword checks plus status pages and around 90 notification integrations. The structural catch deserves saying plainly: one box in one region tells you the service is unreachable from that box, which is not the same as down, and it tells you nothing at all while that box is the thing that broke.

Gatus is Apache-2.0, 12,090 stars, v5.36.0 from May 19, 2026. Everything is YAML, which makes it the natural fit when monitors belong in the same repo as the infrastructure they watch, and its conditions syntax asserts on status code, response time and body content together instead of bare reachability. Note that gatus.io now sells a hosted version too; the self-hosted core stays Apache-2.0.

Upptime removes the server entirely. MIT, 17,157 stars, running on GitHub Actions, Issues and Pages, so checks run on Actions runners, incidents open as issues and the status page deploys to Pages. Two honest caveats: Actions scheduling puts a practical floor near 5 minutes, and the newest tagged release is v2.0.0 from October 13, 2020, even though the repo took commits on September 17, 2026. It works; the tags just do not tell you that.

Picking One

Side project or marketing site: UptimeRobot free. Nothing else gives you 50 endpoints for $0.

Sub-minute detection, no budget: Checkly Hobby, the only free plan in the table that clears a 60-second mean for 10 monitors.

Docker already running, want unlimited monitors: Uptime Kuma on a small VPS, in a different region from whatever it watches.

Monitors belong in version control: Gatus for YAML, Checkly if the checks should reuse Playwright tests.

Uptime and on-call as one product: Better Stack, whose free tier includes the status page and escalation policy instead of selling them separately.

Cron jobs and backups rather than web pages: Cronitor, where the heartbeat model matches the problem.

Open-source project already on GitHub: Upptime, if 5-minute checks are good enough.

Conclusion

The comparison that matters is cost per monitor against detection time, and those two rank these products differently from the pricing pages. On numbers verified September 17, 2026: UptimeRobot Scale is the cheapest paid slot at $0.33 per monitor, Checkly Hobby is the cheapest route to sub-minute detection at $0, and Uptime Kuma deletes the per-monitor question if you will run a box and live with a single vantage point. Count your endpoints, decide how fast you need to know, and run the script against your own list before paying anyone.

Two DevToolLab tools that pair with this: the URL Redirect Checker for finding out your health check is quietly following a 302, and the Latency Percentile Calculator for turning raw response times into a p95 your alert threshold can actually use.

References

Best Uptime Monitoring Tools in 2026 - the original article on DevToolLab, with the full fit table and per-vendor detail
7 Datadog Alternatives and What They Cost - the full observability platforms, priced on one identical workload
Best Sentry Alternatives in 2026 - error tracking, which answers a different question than uptime
Uptime Kuma on GitHub - MIT licensed, source of the star count and release date quoted above
Gatus on GitHub - Apache-2.0, version and license verified here