Promtail is end-of-life: your Loki shipper just lost its support floor

If you still ship logs to Grafana Loki with Promtail, you’re running an agent that reads every log file on the host, holds an open connection to your log backend, and as of March 2, 2026 has no upstream support or security path. That’s the whole story. The version you’re running is the version you keep, and nobody upstream is patching it.

The part to be precise about: this isn’t a “you’ve been unpatched for a year” situation. Grafana deprecated Promtail on February 13, 2025 with Loki 3.4 and put it into a 13-month long-term-support window. During LTS it still got commercial support, security updates, and critical fixes, just no new features. So the urgency isn’t that the agent rotted on your hosts. It’s that the support floor dropped out on schedule, and an unpatched log shipper is exactly the kind of privileged, network-talking process you don’t want sitting on the unsupported list.

What actually changed

The Promtail docs page now reads: “Promtail is end of life (EOL) as of March 2, 2026. Commercial support has ended. No future support or updates will be provided.” That language is final. There’s no extended-support tier to buy your way into.

Promtail’s EOL is the last step in Grafana retiring its entire pre-Alloy agent family. Grafana Agent, in all its flavors (Static, Flow, Operator), went EOL November 1, 2025. Promtail followed four months later. The successor for both is Grafana Alloy, which is Grafana’s distribution of the OpenTelemetry Collector. One binary now does what Promtail (logs) and Grafana Agent (metrics, traces) used to do separately.

One carve-out worth knowing if it applies to you: lambda-promtail, the AWS Lambda log shipper, is explicitly excluded from this EOL notice. That isn’t a long-term blessing. It means lambda-promtail’s status is tracked separately, not by the March 2 date, so check it on its own before you rely on it.

What this means for your environment

The honest scope: this only bites you if you run Promtail. If you’re already on Vector or Fluent Bit, none of this is your problem. The transferable lesson is the one underneath it. An EOL agent that reads every log file and holds a network connection is a quiet risk class. It doesn’t throw an alert about itself. It just keeps working, which is exactly why it sits on the backlog until it shows up in an incident writeup.

If you do run Promtail, the operational reality of the migration is that the config language changes. Promtail uses plain YAML. Alloy uses its own block-based declarative syntax (called Alloy syntax, descended from River in Grafana Agent Flow). Your scrape configs, label rules, and Loki push endpoints all map onto named Alloy components instead: local.file_match for glob discovery, loki.source.file to read entries, loki.process for transform stages, and loki.write as the sink. Components wire together by reference, so a source’s forward_to names a downstream processor or writer. It’s the same pipeline you already have, expressed in a different shape.

The shape change is annoying. The thing that will actually hurt you is state.

Promtail tracks per-file read offsets in a positions.yaml so it can resume mid-file after a restart instead of re-reading from the top. Alloy keeps the same kind of state, but at a different path. If you migrate and the Kubernetes PersistentVolume or host mount still points at the old location, Alloy starts cold. Cold means one of two bad outcomes: it re-ingests logs it already shipped (duplicate lines in Loki, and your dashboards lie), or it can’t find its place and silently loses coverage during the cutover. The migration guide notes the path changed but ships no tested remap procedure, and the exact path lives in the loki.source.file component reference, not the migration page. Confirm it before you touch a PV manifest. Rehearse the cutover in non-prod.

What you need to do

The conversion itself is one command. alloy convert --source-format=promtail --output=<path> <input> reads your Promtail YAML and emits an Alloy config as a starting point, mapping scrape configs, static targets, labels, file-match rules, and Loki endpoints onto the right components. --report gives you diagnostics; --bypass-errors forces best-effort output when something doesn’t map cleanly. The converter targets Promtail v2.8.x, so check your version first.

Before you commit to the rewrite, you can run Alloy against your unconverted Promtail YAML to watch its behavior: alloy run --config.format=promtail <config>. That lets you see whether Alloy ingests your sources correctly before you own a new config file.

What convert won’t do for you, so put it on the checklist:

• Tracing config doesn’t migrate. Redo it by hand if you have it.
• CLI args passed outside the config file aren’t captured. Same for environment variables, which need reconfiguring.
• Alloy’s internal metric names differ from Promtail’s. Any alert or dashboard you built on meta-monitoring (the “is my shipper healthy” panels) breaks silently until you update the metric names. This is the one that bites a week later when you wonder why your shipper-down alert never fired.

On Kubernetes, the grafana/promtail Helm chart is deprecated in favor of grafana/alloy. If you run the Kubernetes Monitoring Helm chart, v4 deploys Alloy via the Alloy Operator and flips onlyGatherNewLogLines to true by default. That’s a safer default (no historical replay when a pod restarts) but it is a behavior change from Promtail, so know it’s there before a restart quietly drops the backfill you used to get.

Should it even be Alloy?

For a Loki shop, yes, with a caveat. Alloy is the lowest-lift path: same push endpoint, first-party conversion tooling, official support. The tradeoff is you adopt Grafana’s proprietary config language, which is friction the day you ever want to leave Grafana.

If backend optionality matters to you, the OpenTelemetry Collector is the honest alternative. It’s CNCF-graduated, vendor-neutral, speaks standard YAML, and ships to Loki through its Loki exporter. You write more config by hand and you don’t get alloy convert, but you’re not locked to one vendor’s syntax.

Pick	Best when	The catch
Grafana Alloy	Loki is home, you want minimal lift	Proprietary config language
OTel Collector	Hedging against lock-in, OTel standardization	Manual config, no convert tool
Fluent Bit	You need raw throughput on tiny nodes	Less expressive routing
Vector	Multi-destination fan-out is the job	Overkill if Loki is your only sink

On throughput, treat the numbers carefully. A 2026 VictoriaMetrics benchmark put Fluent Bit at ~31,300 logs/sec versus Alloy’s ~15,700 under a 1-CPU/1-GiB cap, with Vector on top for multi-destination. Fluent Bit also logged malformed records during container log rotation in that test, and the benchmark comes from a Grafana competitor, so read it as directional, not gospel. If Loki is your only sink and your volume is normal, Alloy’s throughput is not your bottleneck.

My recommendation for a straight Loki shop: Alloy, because the conversion tooling and first-party support make it an afternoon instead of a project. Choose the OTel Collector only if you’re deliberately buying your way out of lock-in and you’ll accept the manual config cost for it.

The real failure mode

The migration is genuinely small. One convert command, a careful look at the positions-file path, a meta-monitoring metric rename, a rehearsal in non-prod. Call it an afternoon for a single environment.

The failure isn’t the migration being hard. It’s letting a privileged, file-reading, network-connected agent sit on the unsupported list for months because it never throws an alert about itself. Log shippers are invisible right up until the day one is named in a postmortem. The support floor already dropped. The only question is whether you move before or after something forces you to.

We watch the EOL and deprecation churn so the agents quietly running your infrastructure don’t age into a liability you find out about the hard way. That’s the job.