SEO Summary: Inflation and rising software costs hit hard last year, leaving many IT shops wondering if they should raise their break/fix rates. Here is my practical guide on why you must adjust your emergency pricing, how to implement it technically, and when to completely sever ties with unprofitable legacy clients.

Did You Raise Your Break/Fix Rates Last Year? (And Why You’re Bleeding Money If You Didn’t)

I remember sitting at my desk last Thanksgiving at TechResolve, desperately trying to resuscitate prod-db-01 for a legacy client who stubbornly refused to move off their ancient on-prem hardware. Four hours, three cold cups of coffee, and a lot of swearing later, the database was up. My turkey was cold, and I was billing them our standard 2019-era break/fix rate. Later that week, after pulling our operational metrics, I realized that after accounting for inflation, vendor licensing hikes, and my team’s well-deserved raises, we actually lost money on that emergency call. If you’re scrolling through Reddit asking, “Did y’all increase your Break/Fix hourly rate last year?” and feeling a pit in your stomach, pull up a chair. We need to talk.

The “Why”: The Root Cause of Stagnant Rates

The root cause of bleeding margin on ad-hoc support isn’t market pressure; it’s pure psychological friction. As engineers, we are wired to solve technical problems, not to have uncomfortable financial conversations with a stressed-out Operations Director who still thinks Windows Server 2012 is “just fine.” We keep our ad-hoc emergency rates low because we fear client churn. But here’s the unvarnished truth: your SaaS toolset costs went up 15%, AWS/Azure compute costs crept up, and payroll isn’t getting cheaper. Subsidizing a client’s refusal to fix their technical debt by keeping your emergency rate artificially low is just terrible system architecture. You are effectively the failover cluster for their bad business decisions.

Pro Tip: Break/fix rates should be painful for the client. If your break/fix rate is within 20% of your managed service hourly equivalent, you are actively incentivizing them to avoid signing an MSA. Make the ad-hoc pain reflect the operational chaos it causes your team.

The Fixes: How to Correct Your Course

1. The Quick Fix (The Blunt Force Rate Hike)

The fastest way to stop the bleeding is a universal flat-rate increase for any account not protected by an active Managed Services Agreement (MSA). Yes, it’s a bit hacky and blunt, but sometimes you just need to apply a tourniquet. We use an automated billing backend, so I literally pushed a patch to our invoicing database to bump the default legacy SKU.

-- Blunt force update to the break/fix billing SKU
UPDATE billing_skus 
SET hourly_rate = hourly_rate * 1.35, 
    last_modified = CURRENT_TIMESTAMP,
    modified_by = 'dvance_admin'
WHERE sku_type = 'AD_HOC_SUPPORT' 
AND is_legacy_client = TRUE;

-- Add a mandatory minimum 2-hour charge for any emergency ticket
UPDATE client_contracts
SET min_billable_hours = 2
WHERE contract_type = 'BREAK_FIX';

It’s not elegant, and you will definitely get some angry emails from clients who only call you once a year when their router catches fire, but it immediately stops the financial hemorrhage.

2. The Permanent Fix (Transition to Retainers)

The real fix isn’t just charging more; it’s deprecating the break/fix model entirely. Just like we deprecate vulnerable API endpoints, you need to deprecate unpredictable revenue streams. You transition them to a baseline retainer. Here is how we structured the pivot during our Q1 reviews:

By forcing the conversation, you convert your noisy, unprofitable clients into stable, predictable workloads. The ones who value your expertise will sign. The ones who don’t will leave, freeing up your pipeline for better things.

3. The ‘Nuclear’ Option (The Offboarding Automation)

Inevitably, you will have a client who absolutely refuses the rate increase but still expects you to answer the phone at 2 AM when their unpatched Exchange server gets crypto-locked. When they reject the new terms, it’s time to invoke the nuclear option: automated offboarding. If they won’t pay the new rate, cut the cord completely and hand over the keys.

Warning: Always ensure your legal obligations (data retention, minimum notice periods) are met before executing an offboarding script. Don’t let a technical solution create a legal liability.

Here is a sanitized snippet of the Terraform automation we use to tear down the secure tunnels and revoke support access for legacy clients who refuse to upgrade their contracts. It physically prevents our engineers from accidentally doing free work or getting dragged into a legacy fire.

# Terraform snippet to decommission legacy client VPN & Support Portal Access
resource "aws_ec2_client_vpn_authorization_rule" "revoke_legacy_access" {
  client_vpn_endpoint_id = var.techresolve_vpn_endpoint
  target_network_cidr    = var.client_legacy_vpc_cidr
  revoke_all_groups      = true
}

resource "okta_user_group_memberships" "remove_support_access" {
  user_id = data.okta_user.legacy_client_admin.id
  groups  = [
    data.okta_group.no_active_contract.id
  ]
  # Drops them from the active 24/7 PagerDuty escalation group
}

Look, I get it. Raising rates feels confrontational. But as a Senior DevOps engineer, your job is to build sustainable, highly available systems. A business model that relies on undercharging for your team’s mental health is the most fragile architecture of all. Update your rates, push the changes to production, and don’t look back.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions