Chaos engineering vendors sit in a weird spot. You're selling something that most engineering teams don't have budgeted yet, to people who are already buried in incident response and feature work. Your pitch is essentially "let's intentionally break things to learn how they fail" - which is philosophically sound but practically hard to get someone to care about when they're firefighting production issues.
Cold email works for chaos engineering vendors. But it works differently than it does for most infrastructure tools. You're not selling a solution to a known problem. You're selling a practice that prevents unknowable problems. That changes everything about how you frame the ask and who you target.
Target Site Reliability Engineers, Not Directors
Most chaos engineering vendors instinctively reach for VPs of Engineering or Directors of Infrastructure. That's a mistake. Those people are thinking about quarterly roadmaps and headcount. They don't spend their day thinking about resilience testing.
Target senior SREs, platform engineers, and staff-level infrastructure engineers instead. These are the people actually running the systems. They're the ones who understand the gap between "our architecture diagram says this is resilient" and "what actually happens when this node fails." They're also the ones who get pissed off when preventable outages happen, and they're actively looking for tools to solve that.
The list is smaller, but the response rate is dramatically higher because you're talking to someone whose actual job depends on system reliability.
Open With a Specific Failure Scenario
Don't open with what your tool does. Open with what happens when something goes wrong that they didn't test for.
Generic openers about "resilience" or "reliability" get deleted. Specific failure scenarios stick because they're visceral - the reader has lived through something similar.
Here's an opening line that works:
When your load balancer fails over during peak traffic, does your database connection pooling actually handle the spike - or is that the moment you find out it's misconfigured?
That's not a question about chaos engineering. It's a question about something they've probably debugged at 2am. It creates immediate recognition.
Other specific scenarios that work: database failover during a deployment, cascading failures in microservices when one upstream service degrades, cache invalidation under high load, or DNS resolution timeouts during infrastructure changes. Pick one that's relevant to their stack and lead with it.
Skip the Pitch - Show a Test They Should Run
After the opening scenario, don't pivot to your product. Pivot to a chaos engineering test they should be running anyway.
This is the key move that separates responses from deletions. You're positioning yourself as someone who understands their infrastructure problems, not as a vendor. The test you suggest should be something they could theoretically run manually - it's not a pitch for your specific platform yet.
Here's what this looks like:
Most teams we talk to haven't actually tested what happens when their primary database region goes unavailable. A quick 30-minute test (kill the primary, measure failover time and data loss) usually reveals one of three things: failover doesn't work at all, it takes 10+ minutes when you need it under 2, or data consistency issues nobody caught in staging. Does [Company] run that test regularly, or is it on the list?
Notice what happened: you described a test, you showed what it reveals, and you made it seem like a normal part of their job. Now the question at the end feels natural - you're asking if they do something reasonable, not trying to sell them something.
The Close: Make It Low-Friction
After establishing that chaos engineering is a real gap, your close should be minimal. Don't ask for a "15-minute call to explore how we can help your team." That's generic and weak.
Instead, ask a specific question that gives them a reason to respond - and that tells you if they're a real prospect:
Do you run chaos tests regularly today, or is reliability testing more ad-hoc right now?
That question does two things: it's easy to answer (yes/no/somewhat), so the friction to reply is low. And their answer tells you everything about whether you should continue the conversation. If they say "we don't really," you know they're a prospect. If they say "we run them weekly," you can ask what gaps they're running into.
Timing and Frequency Matter More Than Most Vendors Realize
Chaos engineering adoption tends to spike after major outages. When a company has just been down for 2 hours and it exposed a failover that didn't work, suddenly "let's intentionally test our failovers" moves from "nice to have" to "we need to do this."
You won't know when those moments happen for your targets. But you can still time for them. Send your first email 2-3 weeks into the quarter - that's when engineering teams have shipped major features and started thinking about infrastructure work. Send a follow-up 10 days later.
The reason this timing works: after feature pushes, teams update their runbooks, upgrade dependencies, and change configurations. That's also when they realize their chaos tests (if they have any) are outdated. You're hitting them when their mental model of what they need to test is fresh.
Expect a Longer Sales Cycle
Chaos engineering vendors typically have longer closes than most infrastructure tools - 4-8 weeks instead of 2-4. That's not a failure. That's normal. You're not solving "our monitoring is noisy" or "we need to centralize logs." You're adding a new practice to their engineering workflow.
That means your follow-ups matter. After the initial exchange, persistence is where most vendors fail. You need 4-5 touches minimum before you can assume someone isn't interested. Space them 5-7 days apart and vary what you're asking - don't just resend the same email.
The Gap Between Knowing This and Scaling It
Understanding the right positioning for chaos engineering vendors is one thing. Actually executing it at scale - maintaining a list of 500+ qualified SRE targets, running multiple campaigns with different failure scenarios, handling replies intelligently, and following up consistently over 6-8 weeks - is another.
A lot of chaos engineering vendors we work with know they should be doing this. They know their buyer, they understand the opening, they understand the close. What they don't have is the operational infrastructure to run it without it taking 20 hours a week of their time. That's the gap - between "I know what to do" and "this is actually running in the background generating qualified meetings every week."