CommPulse

HELP submitted by /u/lwa-asad to r/FinOps [link] [comments]

Honest question, and a disclosure to start with: I am building a tool in this area, so I am biased. I just want to know whether the problem I think exists actually exists for you. Here is the gap as I see it. Most organisations I have worked in my careear as a consultant had good coverage of the two extremes: * Monitoring (Zabbix, PRTG, Checkmk, etc.): tells you that host X is down, right now. * Inventory (Lansweeper, Snipe-IT, Intune, a scanner of some kind): tells you what is installed on host X. What nobody seemed to have was the middle layer: host X runs application Y, application Y is the backend for service Z, service Z is used by finance and by two other applications through some kind of integration, and the person who owns Z is not available right now ( holiday etc). That knowledge lived in three heads and a wiki page no longer maintained. So when something went down, the process was: alert fires, someone asks "what is that box for?", someone else asks "who do we need to tell?", and the answer was assembled from memory, wikies, excel sheets and so on. The CMDB was supposed to fix this. In my experience it never did, because keeping the relationships current was manual work nobody really did, so it drifted, nobody really knew. What I would like to know from people who run this stuff: When a server, a database or an integration fails, how do you today find out which applications and which people are affected? Is it tooling, documentation, or common knowledge? Does anyone actually keep application-to-server and application-to-application dependencies up to date? If yes, how, and what made it stick? Has NIS2 (in EU) or an audit, or an insurer forced you to produce this map? What did you hand over, and how painful was it? If a tool did this, what would it need to do to be worth the effort, rather than being another CMDB that is kind of forgotton? My current assumption is: it has to discover as much as possible itself (what runs where, what talks to what), and it has to be honest about what it does not know instead of pretending the infrasrtruture map is complete. And if in your organisation , the answer is "we do monitoring and keep the other parts in spreadsheet is fine, this is a solved problem", I would genuinely like to hear that too. That is a cheaper lesson to learn now than later, i dont want to finalize a product no one needs. submitted by /u/michaelnielsen to r/sysadmin [link] [comments]

Curious how teams are handling this. Between OpenAI/Anthropic API bills, GPU instances on RunPod or EC2, and vector DB costs, it seems like most places have one big number and no idea which feature or model is driving it. Do you know your cost per request, or per user, for anything AI-powered? Is anyone tracking token spend by feature, or is it all one line item? If you self-host, do you know your actual GPU utilisation, or is it "the box is up"? Has anyone gone through and actually cut this — what worked? submitted by /u/kondamuri [link] [comments]

Genuinely curious how other teams handle this, because at every place I've seen it works differently and mostly badly. The bill comes in, someone says it's too high, and then... what? Is there one person whose job it is to dig in? Does it fall on whoever is least busy that week? Does it just get ignored until finance escalates? Specifically wondering: - Is anyone on your team formally responsible for cloud spend, or does it float? - When the bill jumps 20% month over month, how do you find out why? Dashboards, a tool, or someone manually clicking through Cost Explorer for two hours? - Do you review it on a schedule, or only when someone panics? - Has anyone actually done a proper line-by-line audit, and did it stick or did spend creep back up in six months? Mostly asking because I keep seeing the same pattern — everyone knows the bill is too high, nobody owns it, so nothing happens. Curious whether that's universal or whether some teams have solved it. submitted by /u/kondamuri [link] [comments]

I was building a FinOps view for an AI support workflow and kept staring at the word productivity. Request count, spend, and latency all fit into tidy charts. None of them told me whether a support case stayed closed or came back two days later. That is awkward when the dashboard is supposed to tell me whether the workflow is helping. Then I ran into two recent studies that seemed to disagree. Firm Data on AI surveyed nearly 6,000 executives, and 89 percent reported no productivity impact over the previous three years. AI, productivity, and the workforce used a sample of nearly 750 executives and found positive but uneven gains. The samples and questions differ, so it is not a clean contradiction. I came away thinking that the answer depends heavily on what question you asked in the first place. For this support workflow, I need data from both sides. The provider bill tells me the inference cost. The help desk has handling time and reopened cases. Looking at either one alone is like checking the grocery receipt without asking whether dinner was edible. A cheap draft can still create a lot of cleanup for the person reviewing it. Suppose a support rep spends five minutes prompting the system and gets a draft, then spends another 40 minutes checking and rewriting the answer. That is 45 minutes of human time plus the inference cost. If the dashboard records only the first five minutes, it gives the model credit for work the rep had to redo. A reopened case would make that picture worse. For a first pass, I can take 25 AI-assisted cases and 25 unassisted cases from the same support queue and week, then match them by issue type and the support rep's experience as closely as I can. ZenMux can give me cost and latency for the assisted requests. The help desk supplies the less glamorous half of the story: handling time and reopens. Fifty cases will not settle a company-wide argument, but they are enough to see whether the current dashboard is flattering us. Even then, I will not have proof that AI caused whatever difference I find. I will know whether repair time and reopened cases wipe out the savings I thought I had. If the workflow only looks productive when I ignore the human cleanup, I need to fix the measurement before I expand it. submitted by /u/quietkida7 [link] [comments]

I keep seeing "cost per customer" thrown around like it's a simple metric, but once you factor in shared infra like RDS or a shared EKS cluster, the attribution gets messy fast. Anyone got a practical framework for splitting shared resource cost across tenants without it turning into a spreadsheet nightmare? Would love to hear how teams handle this in practice, not just in theory. submitted by /u/yourcloudguy [link] [comments]

What happens when AI goes down, it is like us-east-1 in AWS going down, work literally stops. Time to go outside and play 😅 submitted by /u/kiwifellows [link] [comments]

I’m hosting a small Python web application on Azure App Service in the Central India region. Right now, I’m using the F1 (Free) plan for development/testing. The problem is that when I try to scale up to Basic (B1, B2, or B3) , Azure shows “Quota Exceeded” for the Central India region. It doesn’t allow me to create or scale to any Basic SKU, while the Standard tiers (S1, S2, S3) are available but are much more expensive than what I need for a simple test environment. Has anyone faced this issue? I’m looking for answers to these questions: Is there any way to request additional quota for App Service Basic SKUs in Central India? Is this a temporary regional capacity issue or a subscription limitation? Would moving to another nearby region be the best option? Are there any other low-cost Azure hosting options that would be suitable for a small web application? I’d like to stay within Azure if possible, but I’m trying to keep the hosting cost as low as possible for a POC/testing environment. Any suggestions or experiences would be greatly appreciated. Thanks! This post is drafted by chatgpt🫥 submitted by /u/Otherwise_Rip_4033 to r/AZURE [link] [comments]

Bottom line, treasury reconciliation for cross border payments only automates cleanly when your payment platform emits structured settlement events instead of swift trace messages. The rail underneath determines what data you can pull into your ERP. We moved off swift wires last year onto a B2B payment platform whose backend runs on cybrid. The reconciliation difference is the data shape. Every settlement event arrives with timestamp, payment id, invoice reference, and rail type as structured fields. Our ERP consumes the webhook and auto posts the journal entry. No manual matching. Key finding from the migration. Manual reconciliation time dropped roughly 70 percent. Period close on international AP went from 5 days to under 2. The fp&a team got back hours weekly that used to go chasing wire confirmations. What still needs human review. Exception cases like partial settlements or fx rate disputes. Volume on those is small but they require judgment so we haven't automated them. For finance teams looking at this, the question to ask your payment platform is what webhook fields they emit and whether the backend is on regulated stablecoin infra. If the backend is swift, automation has a ceiling. If it's on cybrid or a peer, the data quality unlocks real reconciliation savings. submitted by /u/Parking_Pie9457 to r/FinOps [link] [comments]

Ran the same Kubernetes workload across managed providers for an EU SaaS setup: Requirements: high availability, managed PostgreSQL, Redis, WAF, CDN, EU region, €1,500/month budget. Results: Hetzner 614€/mo lock-in 34/100 GDPR 87/100 Scaleway 832€/mo lock-in 46/100 GDPR 89/100 DigitalOcean 899€/mo lock-in 48/100 GDPR 84/100 GCP/GKE 1,264€/mo lock-in 64/100 GDPR 85/100 Azure/AKS 1,418€/mo lock-in 68/100 GDPR 85/100 AWS/EKS 1,652€/mo lock-in 72/100 GDPR 84/100 GKE scores highest on Kubernetes maturity and managed tooling. But the cost is 2x Hetzner for the same workload. The real question for EU workloads: is the GKE operational advantage worth the cost and lock-in delta over Hetzner or Scaleway? For people running GKE in EU production — what tipped the decision? submitted by /u/faouzi_mahmoudi to r/googlecloud [link] [comments]

How are you managing costs? Tracking attribution, etc submitted by /u/sageVsTheWorld to r/FinOps [link] [comments]

Tokensentinel is a tool that watches your token consumption in process with sub ms overhead. The SDK determines 10+ rules such as tool loop, retrieval thrash etc and you can fine tune it according to your app settings with simple args. You can try it for free and check where your app is consuming extra tokens right now. I am also partnering up with few teams on the cloud side features for intervention, slack alerts and budget enforcement, if any of the FinOps team gives feedback, it would be great help for me. Check: https//tokensentinel.dev submitted by /u/Either_Meet_6909 to r/FinOps [link] [comments]

Fascinating quote from AWS's networking team: "We know customers do not like rate-based network charges because it’s hard to predict their cost, which is why we are moving towards flat-rate pricing for new network products." submitted by /u/Much_Preparation_832 to r/aws [link] [comments]

We got our July invoice and noticed that our July invoice was cancelled and rebilled with a significant credit (about 50% of our OpenAI spend). I'm assuming this is related to the discussion in https://old.reddit.com/r/AZURE/comments/1v2kb4d/check_your_azure_openai_bill_we_found_major_gpt54/ but was curious if anyone else saw the same thing? submitted by /u/vedichymn to r/AZURE [link] [comments]

Prompt caching on Claude only pays off if the cached prefix is byte-identical between requests. Sounds obvious written down, but it's surprisingly easy to break without noticing, a timestamp inserted before the cacheable block, a per-user detail placed at the start instead of the end, and the whole cache silently misses on every single call. No error, no warning in the response, just a bill that doesn't reflect the discount it should. Went through a session where this was happening and the cost difference was significant, easily 2-3x more expensive than it needed to be for the same task, purely from cache misses caused by content ordering. Fix was mechanical once identified: move anything that changes per request, timestamps, session IDs, user-specific detail, to the end of the prompt, after the stable system instructions and reference material that should be cached. Separate from caching specifically, long coding sessions also tend to resend full file contents on every message even when the diff is small, and replay the entire conversation history each turn instead of a compressed summary of where things stand. Neither shows up as a mistake in the moment. Both compound quietly across a session into a number that looks wrong a month later with no clear story for why. Wrote up the full audit and the fix here: https://medium.com/@nagatomopedro05/the-hidden-cost-of-long-claude-sessions-2a6cc7655893 submitted by /u/ClickOk5811 to r/aws [link] [comments]

Did anyone else notice that the GitHub status page reported an incident with GitHub Actions, only to deny it 47 minutes later? Our monitors captured it, paged our on-call team, and then GitHub denied that any incident had occurred. https://www.githubstatus.com/incidents/gx7js8bd0jpz submitted by /u/pod_army to r/devops [link] [comments]

Can you recommend either general features to look for in UPS units to stay on during storms or specific models that work properly? Something I have been frustrated by recently is UPS units shutting off when the power flickers during a storm rather than switching to battery. I presume this is because there was a power surge not just a dropout, but it seems to happen with great frequency. As an example, one customer's server is connected to two different 1000VA UPS tower form factor, one from Cyberpower and one from APC. I think they have both turned off instantly during power outages more often than either has actually stayed on during the outage. Both work fine if simply unplugged. submitted by /u/Kamikaze_Wombat to r/sysadmin [link] [comments]

Hi, i don't really know if this the correct place to ask but i hope to get insight and maybe if anyone ever get into the same case. what happen: I was playing with vertex and trying out different model, and after a while want to try claude api from vertex (now they called agent platform) tried to activate the api and run some req, but getting no quota, manually request from console also give no upgrade at all, so i tried contacting the sales support, asking for an increase quota for some sonnet and haiku model, I ask for just mere 20 rpm and 100k tpm output limit increase, because I am just trying out few days later, as of today got an email from ai studio of my billing tier upgraded to tier 3 https://preview.redd.it/gzqn400tkvjh1.png?width=1647&format=png&auto=webp&s=a55dc52f6ec66427d8dc01d1c19a4e842d5d558a I check on my gcp console, now i get the anthropic limit raised to a whopping lot of 2M input, 200k output, and 2k rpm https://preview.redd.it/6lldf52flvjh1.png?width=1853&format=png&auto=webp&s=9debe3966cc109ffb661eb38d3deccb30c06162f what scares me now that my limit are actually increased to the max limit of USD 100,000 and any random shit happen and it potentially ruin my finance. https://preview.redd.it/urg5paexjvjh1.png?width=847&format=png&auto=webp&s=bcde642217a63a23bdb963316d9914a9d651d119 What i want to know did anyone every get into this before? can i actually downgrade to tier 1? as my spending actually small just 1-3usd per month on few months back where can i get the support for this particular issue? Thank in advance :) submitted by /u/x-xiaolongbao to r/googlecloud [link] [comments]

Something looks off on a server, policy blocks installing Sysinternals, and on Server Core there's no GUI either. All of this is built in and works over PowerShell remoting. Most of my work is incident response, which in practice means turning up to networks where I'm not allowed to install anything and being asked to have an opinion anyway. Not an EDR replacement. It's the DIY version for when there's no agent on that box, or you'd rather check yourself than take a vendor's word. Signature , including the catalog-signed system files many Windows binaries use rather than embedded ones: Get-AuthenticodeSignature -FilePath "C:\Windows\System32\suspect.exe" | Format-List * Status should be Valid. HashMismatch means the file changed after signing. Valid isn't the same as safe. What name it was compiled under : (Get-Item "C:\Windows\System32\suspect.exe").VersionInfo | Select-Object OriginalFilename,CompanyName,FileDescription A binary keeps the OriginalFilename it was built with, so a plain rename announces itself where hashing can't see one. The field is attacker controlled though, so it only means something read next to the signature. Unsigned plus "Microsoft Corporation" is loud. Expect noise, roughly 4% of a clean System32 mismatches because Microsoft ships typos and abbreviations. Part of the protected OS set (needs elevation): sfc /verifyfile=C:\Windows\System32\suspect.exe Downloaded rather than shipped : Get-Item "C:\Windows\System32\suspect.exe" -Stream * A Zone.Identifier stream on a system binary is close to conclusive. Timestamps against its neighbours : Get-Item "C:\Windows\System32\suspect.exe" | Select-Object CreationTime,LastWriteTime Timestomping is trivial, so matching timestamps prove nothing while mismatched ones prove a lot. If it's running : Get-CimInstance Win32_Process -Filter "Name='suspect.exe'" | Select-Object ProcessId,ParentProcessId,ExecutablePath,CommandLine Get-NetTCPConnection -OwningProcess <PID> Hashes, and public datasets you can query yourself : Get-FileHash -Path "C:\Windows\System32\suspect.exe" -Algorithm SHA256 Get-FileHash -Path "C:\Windows\System32\suspect.exe" -Algorithm SHA1 winbindex.m417z.com indexes what Microsoft actually shipped. A system binary's name carrying a hash Microsoft never shipped is the clearest signal you'll get. CIRCL hashlookup wraps NSRL and friends, no API key: Invoke-RestMethod "https://hashlookup.circl.lu/lookup/sha1/<sha1>" Query by SHA1, not SHA256. Classic NSRL records carry MD5 and SHA1 only, so SHA256 can't reach them. Coverage skews old, so it's more useful on legacy boxes than a patched 2022 server. One caveat before looking anything up. Submitting a hash is itself a disclosure, and a first ever lookup tells whoever built it that you're looking. What would you add? Genuinely interested in what people check that isn't in here, most of this list came from someone else's answer to the same question ;) submitted by /u/Haunting_Ganache_850 to r/sysadmin [link] [comments]

On the heels of an epic outage, Securence is getting out of their email, web and other cloud online services businesses, with a drop-dead date of November 11, 2026. Feel free to share your comments. Here is the content of an email I received today: First, thank you for your loyalty to US Internet. As you know, USI joined the Metronet family last year. As part of this transition, we are simplifying our product portfolio to focus on delivering fiber internet, voice and network connectivity solutions. We are writing to give you advance notice that the following USI products and services will be retired after Wednesday, November 11, 2026. All Securence services, including: - Standard Email/POP/IMAP Email - Hosted Exchange Mail - Email Filtering (Incoming, Outgoing, Mail Continuity, Archiving and Cyphermail). Hosting services: - Web Hosting - SSL Certificate Services - Domain Registration - DNS Hosting - Managed Database Services VM services: - Backup Storage - VMware Server Hosting Data center network services: - Managed Firewall Email Addresses: - u/usinternet .com - u/usiwireless .com Affected services will remain available through Wednesday, November 11, 2026.Your account uses one or more of these services, and you must transition to another provider before that date to avoid a service interruption or loss of data. Migration instructions and additional resources are available at securence.com/migratefor Securence products or at usinternet.com/migratefor all other services. We recognize this change may affect your day-to-day operations and apologize for any disruption. We are providing advance notice to allow sufficient time to plan and complete your transition, and we remain committed to assisting you throughout the process. You have been a valued customer, and we thank you for many years of service. If you have technical questions or need support, please email us at [ [email protected] or](mailto: [email protected] ) call (952) 253-3290. submitted by /u/MorseScience to r/sysadmin [link] [comments]