In technical and software testing contexts, "killing cats" is a phrase used to describe deliberately causing a process or service to crash or be terminated, usually to test recovery, resilience, or monitoring behavior. It is a controlled form of stress or fault injection applied to systems rather than users or animals. This overview explains how the phrase is used, how it differs from similar terms such as "killing kittens," and how to apply it safely in experiments and diagnostics.
Origins and common usage
The expression comes from informal engineering and testing jargon where extreme or destructive testing is described with vivid language. It is not a formal standard term, but a colloquial way to indicate a deliberate termination of a process to observe what happens. Typical goals include verifying logging, alerting, restart behavior, and graceful degradation. Because it describes an action rather than a metric, it is best treated as a testing practice or a category of fault injection.
How "killing cats" differs from related phrases
While multiple variants exist, it is important to distinguish them clearly. Below is a concise comparison of common variants and their intended meanings in engineering discussions.
| Phrase | Intended meaning | Severity or connotation | Notes |
|---|---|---|---|
| killing cats | Terminating processes deliberately to test robustness | Moderate, controlled | Indicates controlled fault injection |
| killing kittens | Causing very light load or extremely gentle testing | Low severity, gentle | Opposite extreme; often used for noninvasive tests |
| panic testing | Forcing system states that trigger alerts or failsafes | Variable; depends on scope | Focused on monitoring and response |
| chaos engineering | Systematic experiments on live systems to build confidence | Methodological; broader scope | Includes controlled failures beyond termination |
Practical contexts and examples
Engineers might refer to "killing cats" when describing scenarios like killing a backend worker to confirm that a supervisor restarts it, or stopping a network service to verify failover behavior. It can also apply to database connections, message queues, or containerized processes. The phrase is typically used in internal discussions, incident reviews, or testing runbooks to signal that a deliberate termination is planned.
Safe practices for fault injection
Because terminating processes can disrupt services, safe practices are essential. Prefer isolated or staging environments, coordinate with stakeholders, use feature flags or circuit breakers when possible, and document expected behaviors and rollback steps. Define clear success criteria such as recovery time, log completeness, and alert accuracy before running tests.
Common misconceptions and cautions
The phrase should not be interpreted literally, and it is not a formal methodology. It is not a term with a single, universally agreed definition or a fixed set of procedures. Because it is slang, teams should clarify what specific actions the phrase refers to in their context. Avoid using the phrase in production alerts or external communications where ambiguity could cause confusion.
Alternatives and related methods
Instead of informal phrases, many teams adopt precise terms and frameworks. Common alternatives include fault injection, chaos engineering experiments, canary releases, and staged rollbacks. These approaches provide clearer scoping, measurable outcomes, and established safety controls. They also fit better into formal reliability and incident management processes.
Key takeaways
- "Killing cats" refers to deliberately terminating processes to test resilience and observability.
- It is a controlled, moderate form of fault injection, contrasted with gentle testing terms like "killing kittens."
- Use clear definitions, safe testing practices, and documented procedures when performing such tests.
- Prefer precise terminology and established frameworks in production and cross-team settings.
When to avoid the phrase
Because the phrase is informal and potentially ambiguous, avoid it in on-call handoffs, incident reports, or documentation shared with external stakeholders. Replace it with specific actions (for example, terminate process X, simulate node failure) and reference the relevant runbook or experiment ID. Clarity reduces risk and supports effective coordination.