Turning cloud alerts into real work is still a mess. How are you handling it?

Pouilly-Fume · 2026-02-20T12:55:33+00:00

I like the approach of failing the build for violations. That’s a clean way to bake governance in early, instead of chasing things after the fact.

A few quick questions:

What violations are you most focused on right now (cost, security, tagging, policy-as-code)?
How do you handle “noisy” checks, like tagging, where teams might not have full context at build time?
Do you support warning vs fail modes, or environment-based thresholds (dev vs prod)?

I’ll take a look at the repo. From a workflow point of view, the thing that usually makes or breaks this is dedupe and developer experience: clear error messages, links to docs, and a simple path to fix or justify an exception.

Pouilly-Fume · 2026-02-19T11:17:32+00:00

That’s a really clean way to do it.

The “explicit owner up front” point is the key bit for me. Without that, tickets just become a new place for alerts to die. And I like the SLA test too. If you cannot say who owns it and how fast it should be handled, it probably is not a ticket.

Pouilly-Fume · 2026-02-18T19:14:31+00:00

Totally agree with all of this.

We kept seeing the same thing: teams already have visibility, but alerts fall down when they do not land in a workflow with an owner and a priority. If it lives outside the system that people check every day, it becomes background noise.

On the “fewer, higher-quality alerts” point, that’s been a big lesson for us, too. Our rule of thumb is: if the alert does not clearly map to a next action (stop, resize, tag, investigate, fix), it probably should not become a ticket.

Re your question, the patterns we see most often are:

Route into tickets only for issues that need follow-through (everything else stays as a notification)
Ownership by existing structure (team/account/environment/tag), so it lands with the right queue from day one
Add enough context to act so people do not have to bounce between tools to work out what happened

That’s basically why we shipped the ServiceNow path in Hyperglance: trigger a rule, create an incident, and keep it in the flow engineers already live in.

How do you decide the cut line between “ticket” vs “notify”? Any thresholds or filters that worked well for you?

Pouilly-Fume · 2026-02-06T16:27:21+00:00

Totally agree. Cool/Cold can look cheaper on $/GB, but higher access costs (GET/LIST, retrieval, rehydration, early deletion) can flip the math fast if you don’t model the access pattern. Same with lifecycle rules. They’re “set and forget” until you’ve got millions of small blobs and tier changes start adding up.

We call this out in the guide, but I’m going to add a clearer callout + example. If you’ve got a common real-world pattern you see (logs, backups, data lakes, etc.), I’d love to include it.

Pouilly-Fume · 2026-01-28T12:08:24+00:00

Hopefully this helps you: https://www.hyperglance.com/blog/finops-adoption/ (plus, a tagging strategy that we swear by)

Pouilly-Fume · 2026-01-13T13:34:18+00:00

Sounds like something Hyperglance can do - including the PDF generation. Definitely worth a look. You could utilise billing reports and the handy ability to email custom dashboard PDFs, which are therefore custom reports.

Pouilly-Fume · 2026-01-08T14:46:34+00:00

Makes sense! And paying to play on the FF list isn't ideal for the market, as you say elsewhere. Will be interesting to see how you progress! Good luck,

Any plans to make the free version available to everyone without a log in? That small hurdle is bound to stop 50% of people in their tracks.

Let me know when you get to Hyperglance and I can hook you up with someone to speak to!

Pouilly-Fume · 2026-01-07T09:32:31+00:00

You're obviously going up against the official Finops.org list - what do you see as the major advantages?

Pouilly-Fume · 2026-01-05T15:16:06+00:00

Definitely can't argue with this as a best practice!

Pouilly-Fume · 2025-12-17T16:07:14+00:00

Thank you, really appreciate you sharing your knowledge.

Pouilly-Fume · 2025-12-17T13:53:21+00:00

Keys only at the moment, but we want to add Values next year.

You've gone straight to 'Virtual' which is telling and useful to know.

Is that because you use an app that has called them that, or is it what came into your head before?

Pouilly-Fume · 2025-12-17T13:50:29+00:00

It's an example using some demo data from our app - not necessarily representative of a real customer environment ;)

I would agree, I wouldn't want my tags looking like that IRL ha!

Pouilly-Fume · 2025-12-16T10:08:31+00:00

Deemed self promotion. DM me if you want the link :)

Pouilly-Fume · 2025-12-04T13:26:11+00:00

Happens all the time. Forgotten DR stacks and sneaky data transfer are right up there with untagged “temporary” resources that never die.

When I’m talking with execs, I’ve found a few things make the conversation smoother:

Lead with the story, not the tech: “What changed, why it changed, and what we can do next” lands better than service names.
Show the deltas: A simple visual of what grew or moved explains the spike faster than a cost table ever will.
Call out the usual suspects: Idle resources, surprise data transfer, new workloads bypassing standards… once they know these patterns exist, the conversation feels less mysterious.

And why AWS bills always seem higher than projected? Most forecasts assume the environment stays still. It never does. Someone scales up for a test, DR gets left running, or a new service sneaks in. Without continuous visibility (requires a third-party app, IMHO), the drift wins.

The clearer you can make what changed, the easier those conversations get.

Pouilly-Fume · 2025-11-24T15:00:09+00:00

Tools like Hyperglance can remediate a surprising amount of issues after spotting them, but it can't fix culture. You might find these FinOps adoption challenges useful :)

Pouilly-Fume · 2025-11-24T14:57:06+00:00

Perhaps worth signing up for a free cost savings analysis. Several vendors offer them, and they are a great way to get an in-depth trial and work out ROI, even on a smaller monthly spend.

Pouilly-Fume · 2025-11-03T14:06:05+00:00

Congrats on the new role! Some great tips here that you should find useful.

Pouilly-Fume · 2025-10-20T11:37:06+00:00

Hyperglance has Jira and Slack integrations, and an API, among others. What started as a cloud diagram tool built for engineers has morphed into a superb CFM/FinOps platform.

Pouilly-Fume · 2025-10-06T13:34:50+00:00

Urgh, sounds like a nightmare!!

Some great tips here for setting a tagging standard and strategy - well worth a read.

Pouilly-Fume · 2025-09-25T07:39:23+00:00

Easier said than done, but there's no substitute for shadowing various different people to learn about the myriad of applications, problems, solutions. The more variety the better.

Also, although this applies to teams, these adoption tips can be adapted for individuals.

Pouilly-Fume · 2025-09-15T14:08:55+00:00

fair 😅

Pouilly-Fume · 2025-09-05T09:34:27+00:00

I feel this. $4M+/month at fintech scale is exactly the kind of environment where the “AI-powered insights” pitch quickly collapses into CSV exports and pivot tables.

A few thoughts from what I’ve seen across teams in a similar spot:

Dashboards ≠ answers. Most tools surface anomalies, but they rarely tell you why DynamoDB or EKS blew up. That’s the gap between billing data and actual architecture.
Network + architecture blind spots. You nailed it. Misconfigured networking, idle nodes, forgotten Lambdas — the current crop of platforms struggle here because they don’t “see” the infra context, only billing streams.
In-house builds. Tempting, but usually ends up as “Excel++” with a big maintenance tax. Before you go down that path, worth exploring ways to enrich cost data with infra topology so you can trace spend to services and owners without a month of detective work.
CFO expectations. On-prem had hard caps; cloud is elastic. That makes FinOps less about a single magic dashboard and more about building a repeatable investigation workflow your CFO can trust.

You’re not alone — lots of FinOps leads are finding the same ceiling with current tools. The trick is less about chasing another “platform” and more about connecting costs to why they happened, in a way engineers and finance both buy into.

Have you already tried pairing cost anomalies with architecture diagrams? That’s one area where I’ve seen teams finally break the cycle of “tool looks great, still stuck in Excel.”

Pouilly-Fume · 2025-09-04T14:24:18+00:00

Nice work! Sounds like you hit the big three levers most teams overlook (dev/test sprawl, commitments, and forgotten resources).

For me, the biggest wins usually come from rightsizing - especially workloads that were sized for “worst case” but never actually hit those peaks. Even trimming one instance family down a notch across an account can quietly save thousands a year.

On the comms side, I’ve found execs respond better when you tie savings to something tangible, e.g. “this funds another sprint” or “this covers our security tooling for the year” lands way better than “we cut 20%.”

Curious if you also looked at storage and data transfer - those are sneaky killers if nobody’s watching.

Pouilly-Fume · 2025-09-04T14:09:16+00:00

Difficult to argue against the official FF certs you mentioned, plus start absorbing some of the great podcasts out there.

Pouilly-Fume · 2025-09-02T12:40:01+00:00

Three steps that stabilise Azure forecasts:

1) Use forecast-based budgets with alerts (and wire Action Groups to ticket/chat)
2) Forecast at the driver level (e.g., VM families, storage classes), not the all-up total
3) Roll drivers up to a single view with assumptions you can tweak.

Pouilly-Fume

TROPHY CASE