Gremlin

Name: Gremlin
Brand: Gremlin

The Reliability Management Platform for high-velocity engineering teams

Est 2016|Valuation $143M|Raised $26.8M|36 Ref Customers

LinkedIn 12K|Web traffic 8K|FTEs 62|HQ San Jose, California, US

MarketsChaos Engineering

Published Oct 15, 2026

01Common complaints

- Company sizes or stages where this product is overkill or insufficient - Early-stage startups without mature SRE practices and observability: chaos engineering can consume resources without clear ROI if basic reliability practices are not in place. - Industries or use cases where competitors are clearly superior - AWS-only workloads where an AWS-native solution such as AWS FIS may offer simpler integration and procurement. - Kubernetes-only teams that prefer open-source/GitOps-native tooling such as LitmusChaos or Chaos Mesh. - Technical requirements that this product cannot meet - If a fully air-gapped operation is required but the organization cannot operationalize Private Edition’s self-managed burden. - Budget constraints that make alternatives more appropriate - If cost sensitivity is high, open-source tools or AWS-native services may be more appropriate. - Specific workflows or integrations where the product falls short - If deeply customized experiments beyond an agent-based fault library are required, open-source frameworks may provide greater adaptability. - Red flags in the buying process - If pricing is not sufficiently transparent for procurement or requires long commitments before proving value. - If security teams cannot approve the required agent capabilities. - Current limitations acknowledged by the vendor - The reviewed materials do not provide a comprehensive public list of limitations; documentation emphasizes compatibility and low overhead but lacks detailed operational limits. - Features on the roadmap (not yet available) - No clear public roadmap commitments were found in the reviewed sources. - Scale limitations (at what volume/size does it break down?) - Vendor-published claims reference large host counts, but methodology is not provided; procurement should request architecture references and documented limits (agent fleet size, API rate limits, concurrency, and RBAC scaling). - Security or compliance gaps - Public security posture references hosting environment compliance but does not clearly document buyer-verifiable certifications (for example, SOC 2 Type II availability); procurement should request evidence. - Technical debt or architectural limitations mentioned in reviews - Not sufficiently evidenced in the reviewed sources due to limited accessible review text. - API limitations or integration constraints - Gremlin lists integrations with observability tooling (CloudWatch, Datadog, New Relic, Prometheus) in public materials; API and SCIM depth should be validated in technical evaluation and security questionnaires.

Deal disqualifiers: what makes a POOR fit

Low operational maturity (no clear monitoring or service ownership).
Regulated environments where privileged agents are unacceptable and a private/offline deployment is not feasible.
Very small teams that cannot justify the cost or process overhead.

Why some customers left for competitors (churn reasons)

Not well evidenced in the accessible public review text.
Plausible churn drivers based on market dynamics (to be validated with customer references):
- Adoption of cloud-native, vendor-native offerings for single-cloud footprints.
- Migration to open-source tools for cost control and customization.
- Switching to competitors for broader reliability workflows or platform consolidation.

02Why they buy

- Competitive advantages supported by available evidence - Public review volume is limited, making it difficult to validate unique selling points solely through customer voice in the reviewed sources. - Community sentiment and vendor materials indicate Gremlin provides educational resources (for example, a certification program) that some users cite positively. - Unique features and capabilities competitors lack (based on documentation and public material) - Broad environment coverage, including Windows support and a Private Edition for self-managed deployments. - Combination of fault injection capabilities and vendor-described "Reliability Intelligence" features, though procurement should validate these capabilities during evaluation. - Differentiation from competitors based on reviews - There is insufficient accessible review detail to strongly assert differentiation based on user sentiment alone; hands-on evaluation and customer references are recommended. - Value propositions with evidence from case materials - Vendor and community content supports use for GameDays/FireDrills and structured experiment planning and recording, but independently verified ROI metrics are limited in the reviewed sources. - Areas where competitors have advantages - AWS FIS: AWS-native integration and IAM alignment for AWS-focused organizations. - Open-source alternatives: cost control and customization. - Competing commercial offerings: trial availability and platform consolidation options.

Why customers chose this product over alternatives

Cross-environment coverage (clouds, Kubernetes, Windows, on-prem via Private Edition) is a commonly cited vendor differentiator versus cloud-specific options such as vendor-native chaos services.
Enterprise workflow features (scenarios, safeguards, reporting) are presented as differentiators compared with open-source tooling.

03Field reports

Direct quotes from Gartner Peer Insights, Reddit, TrustRadius, G2, HackerNews

- Gartner Peer Insights (accessible page snippets) - A "likes/dislikes" snippet indicates a reviewer describing fault injection usage and common failure types (resource, blackhole, latency) and JVM-related injection attempts; the visible snippet reads positively but represents an individual reviewer and should be interpreted cautiously. - Full review text may require interactive access; snippets alone are not sufficient to represent the full review set. - G2 - G2’s Gremlin review page (French locale) indicates insufficient review volume on that dataset to provide strong buying insights, suggesting limited coverage on that platform. - Reddit (community discussions about chaos engineering tools) - In r/sre, one commenter noted that Gremlin offers a free Chaos Engineering certification that was regarded positively by that commenter. - In r/kubernetes, one commenter stated: "Gremlin has to drop integrated testing because they can't (as of yet) know your infrastructure." This reflects a community perspective that may refer to a past or context-specific product capability. - Community threads generally indicate that chaos engineering programs often fail due to organizational readiness, culture, or overhead rather than tool limitations. - HackerNews - Search attempts did not surface a definitive high-signal Hacker News discussion in the accessible results set; further manual search may be needed to locate relevant HN threads. - TrustRadius and other forums - Public excerpts and summaries exist but complete context and representativeness may be limited without direct access or login.

Balance: When possible, include both positive and negative reviews

- Review availability challenge - Gartner Peer Insights content exists, but access to the complete review set and negative critiques may be limited without login or interactive browsing. - G2 indicates insufficient review volume to draw strong conclusions from that source. - What can be concluded from available evidence - Positive themes (from vendor materials and some user snippets) - Breadth of fault injection types (CPU/memory/I/O/network/process/time, etc.) and safety mechanisms (abort/halt controls, blast radius limits). - Usability for structured GameDays/FireDrills, planning, execution, and recording observations (as indicated in community tutorials and vendor materials). - Negative themes (from community sentiment and buyer risk factors) - Organizational readiness and process overhead are frequent blockers; some engineers consider chaos engineering premature unless the organization has sufficient maturity. - Potential gaps in environment-aware integrated testing were mentioned in older community commentary. - Security reviews can be complex due to the nature of fault injection agents requiring elevated permissions.

Common criticisms and complaints (support issues, bugs, missing features)

- From the public sources reviewed, the most recurrent complaints are related to: - Cost and accessibility for smaller teams (third-party summaries indicate limited free-tier availability and enterprise positioning). - Cultural and process overhead required to run experiments safely. - Security/permissions friction associated with privileged agents. - There is insufficient public evidence in the reviewed sources to quantify support responsiveness or to identify specific recurring bug patterns.

Specific outcomes customers achieved (with metrics when available)

Vendor materials cite large-scale usage and adoption claims, but independent verification was not found in the reviewed sources.
Specific, quantified customer metrics were not surfaced in the accessible sources; procurement teams should request customer references with verifiable KPIs (for example, MTTR reduction, incident rate reduction, SLO attainment).

Deal-breakers and reasons customers didn't purchase

Not directly documented in the accessible reviews; likely deal-breakers include:
- Requirement for fully self-hosted/offline operation where Private Edition is not acceptable.
- Refusal to deploy a privileged agent in production.
- Limited budgets or preference for open-source alternatives.

Case Studies

- Detailed customer success stories with metrics - Gremlin publishes tutorials and content describing usage patterns such as GameDays and FireDrills, and references use in financial services scenarios. - Independent, quantified case studies with clear methodology were not strongly surfaced in the reviewed sources. - Specific results and quantified business impact - Vendor marketing emphasizes scale and adoption and suggests improved uptime and reduced outage impact, but independently audited ROI calculations were not identified in the reviewed sources. - Implementation details and time to value - Private Edition materials indicate customers must set up and maintain the private deployment themselves, implying added lead time and operational responsibility. - Challenges faced during adoption and how they were resolved - Common adoption hurdles (inferred from community sources and the product’s nature): - Gaining approval to run controlled failures. - Defining blast radius, abort conditions, and monitoring. - Aligning stakeholders across engineering, security, and business owners. - Note when metrics are vendor-published without independent verification - Vendor-reported adoption and usage figures are presented in some materials without disclosed methodology; treat these as vendor-published metrics and request substantiation.

04Best fit

Company sizes: specific employee counts and revenue ranges

Likely best fit
- Mid-market to enterprise organizations with multiple services/teams and significant production-impact risk.
- Revenue profile: larger organizations where the risk and cost of downtime justify a dedicated reliability investment.
Possible fit
- Smaller high-growth SaaS firms if they operate distributed systems and have mature SRE practices.

Industries and verticals where adoption is strongest (with customer examples)

Financial services is frequently referenced in vendor content and tutorials.
Also commonly applicable to marketplaces, e-commerce, SaaS, and organizations practicing SLO-driven operations.

Roles and personas: decision makers AND end users

Decision makers
- VP Engineering, Head of SRE/Platform, CTO, and security leadership for agent permissions and risk acceptance.
End users
- SREs, platform engineers, service owners, and incident commanders.

Pain points and challenges the product addresses

Identification of hidden reliability risks in distributed systems.
Validation of monitoring and alerting under simulated failures.
Preparation of incident response via GameDays and fire drills.
Increasing confidence during migrations (for example, Kubernetes or cloud migrations).

Qualification criteria: what makes a GREAT fit

Mature observability (metrics/logs/traces) and defined SLOs.
Clear ownership model and incident management processes.
Willingness to run controlled tests in production or realistic staging.
Need for cross-cloud/hybrid/Windows support or requirements for structured safety controls.

05The pitch

What the product does (core value proposition in objective terms)

- Gremlin is a commercial chaos engineering (fault injection) and reliability testing platform used to run controlled failure experiments against infrastructure, platforms, and applications to validate resilience and improve incident readiness. It supports running experiments on hosts, containers/Kubernetes, and cloud environments, with safeguards intended to reduce unintended blast radius. Official product materials describe the offering in terms of safety, usability, and security in its approach to chaos engineering. - Gremlin offers a capability set labeled "Reliability Intelligence," which includes pre-configured tests intended to detect common reliability risks (press coverage has described a "Detected Risks" concept).

Target market and market positioning

Targeted primarily at SRE, platform engineering, and reliability/operations teams in mid-market to enterprise organizations that run distributed systems and seek proactive resilience testing (vendor materials reference regulated industries such as financial services).
Gremlin targets enterprise customers and emphasizes controlled experiments, scenarios/runbooks, and organization-wide reliability practices in its messaging.

Get a comprehensive analysis of Gremlin including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →