Cleric has been ahead of the curve from where the industry has gone so far. We use tools like Cursor, and at times, we’ve found Cleric to be a lot better at feature work, and people use it for things like working across multiple repositories. When something that’s essentially designed for operational support and SRE work is doing a great job at that as well, it’s just a testament to how good the product is.
Affaf Ahtisham, Head of Engineering at LaunchGood, described a recent morning: “There was a complex security incident on our platform, and while I was getting ready to take the kids to school, Cleric already had investigations in place. Then within the time of taking the kids to school and coming back, which is 30 minutes or less, the engineers already understood the problem and were reviewing the PRs that Cleric proposed.” Previously, this kind of work would have taken his team half a day to do manually.
LaunchGood is a global marketplace for giving, connecting over 2 million donors with some of the largest charities around the world. They have passed over $1B CAD raised. Inspired by the mission, Affaf joined the company in 2024; previously, he was a Director of Engineering at HashiCorp, leading the teams building HashiCorp Vault. “LaunchGood was at an inflection point of growth and they were going through a massive rebuild initiative. It was an opportunity to help grow a culture based around a high degree of reliability and engineering excellence.”
Cleric has helped them get there. Before trialing the tool, LaunchGood’s engineering team had already embraced agentic engineering, and around 60% of code being committed was by agents. “These days, we’re above 90%,” says Affaf. “Tools like Cleric have been really helpful in terms of understanding how we can augment human skills with things that would typically be grunt work.”
The team at LaunchGood trialed several tools for incident management and production investigation. With a globally distributed team, Affaf says, “it was about helping engineers do their job in a manner that they’re not struggling at 2 AM.”
It took them a bit of time to land on the right solution. “We love incident.io for incident management—it’s been a great tool for us and still is. In terms of incident response, we tried many versions of their agentic product line, including their latest offering, which they’ve rebranded as Nexus Investigate. And it was ok, but what Cleric has is substantially different.”
LaunchGood piloted Cleric in early 2026, to get ready for the Ramadan surge when traffic on the platform can spike up to 15x. “We had a specific target of reducing the amount of time it takes us to respond to incidents,” says Affaf. “And the first weekend with Cleric, there was this a-ha moment from one of our on-call engineers just coming online. Already Cleric was triaging the situation, providing its feedback and its reflection, which was generally accurate, and it was opening up a PR—all of that was happening without much human steering.”
During the Cleric pilot, they kept incident.io’s agentic tools running for a while. “It was very interesting—we’d have an incident.io channel, and an engineer would come in and add Cleric. When we compared the two results, there was a night and day difference between Cleric getting things right almost all the time, and right away as well.”
When Affaf considers a vendor these days, the biggest question that comes to mind is “can I just build you in a weekend or a week?” With Cleric, the answer was a clear no. “Hands down, the ROI for us has been tremendous,” Affaf says.
It’s been obvious to the team that building something similar would come at a high investment and require significant expertise. “The amount of knowledge Cleric has on our core systems is indicative of how much care has been put into the tool,” says Affaf. “We don’t see it as another agent that just grabs the logs and provides a summary. A lot of deeper engineering work went into enabling the right insights to be surfaced at the right point in time, and to show the work. With the other tools we’ve tried, you get a black box, or something that has too much detail while the output is still not there.”
Datadog 19:30 Triggered: Rest Api Facade SLO at risk
Currently there’s an increase of 5xx errors in rest-api-facade increasing the burn rate and consuming the error budget for the SLO
Completed 6 investigation steps
19:40 Summary
The rest-api-facade SLO burn rate alert is caused by payout-service Redis authentication misconfiguration introduced in a deployment on 2026-08-26. [1][2] Datadog
Recommended fix: update the Redis authentication settings in payout-service task definition :38 so they match the Redis instance.
Building a good agentic workflow that really supports the team takes a lot of time. As Affaf puts it, “You can always build an MVP, but then it’s like, how do you operate and maintain it over time? Getting the core primitives right, like an agent’s memory and how it builds a knowledge base over time, isn’t a problem you can just throw people at and expect better results—that can put you down a very bad rabbit hole, burning a lot of tokens and money but not getting a very good return.”
Before Cleric, an on-call engineer would have to go to three different data sources and multiple dashboards to try to put the pieces together. Now, Cleric investigates, provides a hypothesis, and engineers can respond to that and direct Cleric on what to do next. “It’s allowed our team members to really focus on the root causes of many of these issues, and understand the systems better themselves. And if they know the systems better, they can in turn inform Cleric better.”
Cleric has helped the team put some especially tricky issues to bed. “Early on, we had this really weird race condition bug that we’d tried multiple times to fix. We’d spent well over a month having engineers woken up from their sleep and trying to understand why certain services were failing over and over again. Sure enough it went off again and Cleric was engaged—within five minutes it was able to come to a root cause. After six weeks with countless engineers who are ex-Amazon, ex-Google trying to solve this problem, we were finally able to fix it with Cleric. Of course it was due to a single line of code.”
🎉 Fixed: The number of tasks is lower (3.0) than the desired on Service
🎉
After 20+ alerts, many engineers woken up from sleep, 3 PRs and over a month of #inc-239-sev3-number-of-running-tasks-for--is-below-desired-c being open…we think we may have found a resolution 🙂
Today the monitor went off again. @Affaf and I asked Cleric to
investigate, and after some back-and-forth it pinpointed a specific error:
TypeError: Cannot read properties of null (reading 'toString'). This was lining up with the
time of the crash. Maybe we were on to something?
Cleric produced the specific endpoint: "/v4/?".
The user has a donation record for year 2025 with a
null value in one of the CSV field. When toString() is called on the null value, people
lose sleep 🙂
We were able to reproduce the bug. Calling the endpoint would reliably return a 502 and take
down 1-3 ECS tasks every time and kick off the monitor shortly thereafter. Thanks
@Hammad for reigning me in 😛 This only occurred for this specific
user’s donation dataset, which made it extremely difficult to reproduce without a precise trace.
We deployed the fix, hit the endpoint again…and clean response. No crashes.
Monitor is quiet… for now. Early Eid gift for us all 🙂 (edited)
The time to resolve the majority of issues, Affaf says, has been reduced by an order of magnitude. “95% of the time or even higher, Cleric will get it right and we can remediate in less than 10 minutes.” They have confidence that anything falling outside that bucket is a true problem, so they can declare an incident and get the right people involved. “We can better manage our expectations on how something will go, which has been very helpful.”
At this point, Cleric has become so reflexive in the organization that when a product manager or account manager opens a support ticket, they’ll often start by asking Cleric to investigate, and even implement a fix without involving an engineer at all. “Since people are able to self-serve more, it’s making our lives a bit easier,” Affaf says.
The company’s goal this year is to have every single team member at LaunchGood ship at least one change on the platform. “That muscle memory of working with agents has started to emerge within the entire organization. And it goes back to some of the things that we’ve seen with Cleric.”
One of the features that stood out was Cleric’s multiplayer experience: “We’ve really enjoyed being able to collaborate on investigations and steer the agent together. That was foresight because now you see everyone talking about multiplayer as if it’s the latest thing, but Cleric already had it earlier this year.”
This kind of innovation gives the team confidence that they’ve invested in a product that will continue to stay a step ahead of the industry. Which is important because the more the team uses Cleric, the more it learns, and the less attractive it becomes to build or buy an alternative. “With products like Cleric that are really good at learning, it’s like they’re a team member,” Affaf says. “You’re investing in their growth, and it’s not easy to simply replace them. You’ll have the pain of retaining someone new coming in.”
Start for free, or talk to us about a plan built for your team’s scale and security needs.