▲ 18 r/platform_engineering+2 crossposts

Open sourced a tool that collapses millions of log lines into handful of distinct patterns before you feed it to an LLM (Lossless- compression)

When I feed logs to an LLM during incident resolutions or debugging, it either blows my token context window or the grep trims the log file, leading to the interesting log lines getting skipped.

Most of logs are anyway the same handful of message templates repeated over and over with different values, so the context window gets filled with near-duplicates, which just bring up the processing time and token costs.

ctrlb-decompose collapses the file into its distinct patterns that repeat, plus typed variables and stats on the values that change. I have seen 1.2 million lines cut down to just 40 patterns, which then goes into Claude, thus cutting down token by over 95%, reducing the token cost.

Let me know what you think!
https://github.com/ctrlb-hq/ctrlb-decompose

u/Loud_Mousse9210 — 1 day ago

▲ 15 r/platform_engineering+8 crossposts

Daily DevOps Interview Questions - Day 1: These 3 scenarios trip up most freshers. Can you solve them?

Hey r/devopsjobs

I've been mentoring folks preparing for DevOps/Platform Engineering roles and noticed most "interview prep" content is just theory - "What is Kubernetes?", "Explain CI/CD".

Real interviews at product companies are scenario-based. They give you a situation and expect you to debug it.

So I'm starting a daily series of real-world scenarios. These are beginner-friendly but practical - the kind you'll actually face on the job.

Day 1 - 26 July 2026

Scenario 1: The Restarting Container

You just joined as a junior DevOps engineer. A developer reports:

You run docker ps and see: Restarting (1) 30 seconds ago

Question: What's your first debugging command? What are you looking for? What's your tracing path?

Scenario 2: The Registry Rejection

Your Jenkins pipeline suddenly fails at "Push to Registry" with:

denied: requested access to the resource is denied

Same pipeline worked yesterday. No code changes.

Question: What are the 2 most likely causes? How would you verify each?

Scenario 3: The Pending Pod

You deployed a new microservice to Kubernetes. Pod stuck in Pending for 10 minutes.

kubectl describe pod shows:

0/3 nodes are available: 3 Insufficient cpu.

Question: What does this mean? What are your 2 options to fix it without adding new nodes?

Drop your answers in the comments! I'll post the solutions tomorrow with explanations.

If this is useful, I'll keep the series going daily. Let me know what topics you'd like covered - Linux, Docker, K8s, Jenkins, Terraform, Ansible, Monitoring - all fair game.

If you want to follow complete prep path : https://youtube.com/playlist?list=PLqOrZmpwbWUKRQTrFpqAKhChaTq0l5bIw&si=XSgYUZpHC9cuJnh-

u/BookkeeperAutomatic — 1 day ago

▲ 3 r/platform_engineering+1 crossposts

Trying to model an incident response agent

I'm trying to model an agent that gets triggered whenever a production incident occurs. I'm new to the SRE side of things and I'm looking for inputs on a few things based on your past experiences.

Whenever an incident occurs, what are some of the most common reasons? For example, it could be a false alarm, it could be an issue due to a new upgrade, network issues or a crash due to some bug in one of the services etc. Out of 100 incidents, what are the chances that it could be a false alarm, upgrade issue, bug in code etc.

I want to know what are all the common issues or reasons that I can add as part of a v1 for my agent? How do I think through this as I've never worked on such a thing till now?

reddit.com

u/pomatotappu — 4 days ago

▲ 4 r/platform_engineering+1 crossposts

Pricing per host doesn't makes sense to me

The way we operate is we have teams in different regions having multiple AWS accounts. Similar way is on GCP. But the thing is that we have lot of nodes & clusters which are not heavy in terms of generating APM data. When I say heavy I mean like 1TB/day - 3 TB per day per host. I believe we are generating data around 30GB-50GB per host per day data which I believe is average or maybe lower side of spectrum. So, when I look around what would it cost me for a BYOC observability tool, its insanely high for per host pricing tool as compared to ingestion based pricing tools. So, I am really confused why companies put per host pricing ? Also is my assumption right that 30GB-50GB per host per day data generation is average in industry ?

reddit.com

u/ayushbaba — 6 days ago

▲ 11 r/platform_engineering+5 crossposts

Backstage is open source, but how much open-source infrastructure do you still need to build around it?

Backstage gives teams an open-source developer portal, but the portal is only one layer of an internal developer platform.

Behind it, teams still need to connect and maintain:

CI/CD and application deployments
Environment provisioning and promotion
Kubernetes workload management
Observability and developer context
Access control and policy enforcement
Continuous reconciliation and operational reliability

This raises an interesting question.

Should every organization assemble and maintain these capabilities from separate projects, or should the FOSS ecosystem provide more complete, connected platforms that remain open, modular, and replaceable?

On August 27, Kelsey Hightower and the OpenChoreo maintainers are hosting a session on what it really takes to build a complete internal developer platform around Backstage.

The discussion will look at the engineering work behind the portal, how Kubernetes and cloud-native tools fit together, and the trade-offs between building every integration yourself and adopting an open-source platform that provides them as a connected system.

I am part of the OpenChoreo team, so sharing this with full disclosure. OpenChoreo is an open-source platform built for Kubernetes.

Session details:

https://platformengineering.org/events/what-it-really-takes-to-build-an-internal-developer-platform-with-backstage-2026-08-27

u/Waste_Bat_4525 — 10 days ago

▲ 2 r/platform_engineering

Would an AI that investigates production incidents before an engineer gets involved actually be useful?

I've been thinking about a problem I keep seeing in infra/DevOps work.

A production alert fires and someone has to manually jump between logs, Grafana/Datadog, Kubernetes, deployment history, GitHub, cloud metrics, etc. just to figure out what actually happened.

I'm wondering if a useful chunk of that investigation could be automated.

The idea would be something that, when an alert or deployment failure happens, automatically:

investigates logs, metrics and traces
checks recent deployments/commits
correlates changes with when the issue started
checks Kubernetes/cloud infrastructure
identifies the likely root cause and supporting evidence
suggests a remediation
if a code/config change is required, generates a PR
waits for an engineer to review/approve it
after deployment, verifies whether the issue was actually resolved

For example:
Instead of an engineer starting from scratch, the system might come back with:

I'm not really thinking about fully autonomous production changes initially. More like an AI first-line SRE that does the investigation and prepares the fix, while engineers stay in control.

I'm trying to understand whether this solves a meaningful enough problem or whether existing observability/SRE tooling already gets teams most of the way there.

For people running production systems:

How much engineering time do you actually spend investigating alerts/deployment failures?
What's the most repetitive part of incident investigation today?
Would you trust a system like this to read your infra/logs if it couldn't make changes without approval?
Would automatic root-cause analysis be valuable by itself, or would it need to generate the actual fix/PR?
What integrations would be essential? Datadog? Grafana? Sentry? Kubernetes? AWS? GitHub?
What would make you immediately say "there's no way I'm giving this access to production"?

I'd especially like to hear from founders, SREs, DevOps/platform engineers and engineers at smaller teams where dedicated SRE coverage is limited.

Not selling anything here I'm trying to understand where the actual pain is before building too much.

reddit.com

u/No-Assistance8317 — 9 days ago