From October 7–9, 2025, the Convention Centre Dublin hosted SREcon EMEA, the premier gathering for engineers dedicated to site reliability, distributed systems, and operational excellence. Organized by USENIX, this event brought together hundreds of SREs, platform engineers, and infrastructure leaders from across tech companies based in EMEA. The conference is known for its culture of critical thinking, deep technical insights, and continuous improvement, offering a mix of keynotes, hands-on workshops, and hallway conversations that spark innovation and collaboration. This year’s edition stood out for its strong focus on AI and reliability, with over 16 sessions exploring how machine learning and large language models are reshaping observability, incident response, and infrastructure scaling.

We sponsored the event for one more year

For us, being there as a sponsor was more than just a branding exercise. At Criteo, we have a strong and highly skilled SRE team that takes care of our systems and platforms. They always have our back, especially in these upcoming days with Black Friday.

Being present as a sponsor allows our team to engage with other companies and SREs about resilience, scalability, and operational excellence — goals we share across all our tech teams. Thanks to everyone who stopped by and dedicated some of their time to talk with us. We enjoyed every moment of the interaction. 😃

Notes from Thomas

I attended SREcon for the first time and I liked the event’s size: enough people to engage with and a variety of talks, yet the venue stayed calm and cozy. Connecting and sharing with others led to insightful discussions.

Criteo hosted a booth to promote our open positions. Beyond hiring, it sparked great discussions with attendees and speakers. I met several remarkable people and exchanged ideas about Kubernetes, our work, and the tech ecosystem.

Highlighted talks

Among the talks I listened to, two particularly stood out to me.

Leader election: pitfalls and alternatives
Andrew Medworth, a Staff SRE at Google, delivered a talk that was both a retrospective on a past failure in the Google Cloud Router product and a summary of good design patterns. I liked how the talk offered general advice to guide anyone building large-scale systems, then addressed more complex issues.

This talk suits a broad audience: those using prebuilt systems and patterns receive practical advice and learn how safe leader election systems avoid issues. On the other hand, it also suits experts who need to optimise or build complex systems based on election mechanisms.

I would definitely recommend this talk, as leader election is at the core of many systems today.

Performance Consistency in the Cloud
The talk from Nati and Sercan, both working at AWS, was very insightful for Criteo engineers because, albeit it talks about performance predictness on the Cloud, a wide majority of the challenges listed are completely relevant for our on-premises environment.

The talk first provides the context of where and why such performance predictability matters — which was a nice way to introduce all the attendants to the reasons that pushed the speakers to write this talk. Actually, per Criteo business, we run latency-sensitive workload to bid advertisement placement on the internet. This has led to work on performance predictability for years on our On-prem environment: at the network level, at the hardware level, and at our container platforms level, which runs directly on bare metal (not running VMs is the core difference with most cloud services).

The presentation focused on the cloud provider’s point of view, which represents more or less the role that the Criteo Infrastructure department holds internally. The talk was really interesting, as our infrastructure is evolving, and some challenges (such as remote storage) have not yet been encountered. It was also interesting to see P-state mentioned explicitly, as it is also explored for sustainability reasons.

Discussion Track
I also had the occasion to participate in the discussion track, allowing participants to organise into small groups and discuss specific topics. On this occasion, I discussed with some peers how to make SRE teams more focused and how to handle unexpected work in our backlogs — a topic my team has been struggling with for years, as we manage the Kubernetes service for the entire company at Criteo.

SREcon was definitely a good experience, and I truly appreciated all the discussions we had with various other participants.

Notes from Guillaume

So I went to SRECon 2025 in Dublin. The Convention Centre is a vast and magnificent building, which creates a cozy and quiet atmosphere that contrasts with what I have experienced before with Devoxx or Snowcamp, where the crowd is buzzing and loud. Also, the organization was as smooth as it could be, so kudos to all the team behind it.

I’d like to highlight the choice for a dedicated Slack workspace to handle the event’s global communication and questions to speakers. Very wise choice in my opinion, since most of the attendees use Slack on a daily basis, it’s simple and efficient.

My general overview of the conference is:

• AI, AI everywhere. Although it is often presented as a new challenge for SRE engineers to deal with this new technology, it is also viewed as a powerful tool to enhance observability, particularly in incident detection and remediation.
• Advanced. Topics were highly technical and centered on specific SRE challenges or experiences. This is not suitable for junior or less experienced SRE engineers.
• Adequate talk format. A 20-minute or 40-minute top talk duration is enough to make relevant points without going into too much detail and overwhelming attendees. I appreciated that format. I did not try any of the discussion tracks, though.

Highlighted talks

Among the talks I attended, two resonated more with my own experiences.

The Bitter and the Sweet of Running a Planet-Scale Build & CI Stack at Google
First one was “The Bitter and the Sweet of Running a Planet-Scale Build & CI Stack at Google“ from Tomasz Koczorowski, Engineering Manager at Google, based in Munich, Germany.

Tomasz belongs to the team at Google that seems to be the alter ego of our Build Services at Criteo. During his presentation, he explained what exactly building a continuous integration stack at Google meant in terms of figures, challenges, and key solutions to achieve this.

It might seem obvious, but still kind of reassuring: it looks like we are trying to solve the same kind of issues at Criteo, and are ending up with the same kind of solutions. I liked the talk because I could relate to it a lot, but I missed some implementation details.

Some key points:

• Providing developers with a unified technology-agnostic solution for continuous integration. They use a home-made tool, “Blaze”, based on Bazel.
• Decomposing the overall build into “Actions”, we call them “COps” for “CI Operations” in our system.
• Heavily rely on cache to be able to handle the load of daily actions as we do.
• Large figures: Hundreds of PB/days of build output, billions of cores and petabytes of RAM to handle the load, 100k+ users and billions of compile actions per day.
• The whole CI stack is maintained by <20 SREs, and they organize their time with 50% for projects / 50% for support-related tasks.

From Vibes to Outages: Riding the AI Code Wave
The second one is “From Vibes to Outages: Riding the AI Code Wave“ from Sylvain Kalache, AI Labs lead at Rootly.

Sylvain discussed the AI-generated code surge and its impact on SRE teams. He began by stating that AI is here, whether we like it or not, and we must address it. As SRE engineers, we have reasons to be concerned.

Some interesting figures that were given during the speech:

• 84% of developers use GenAI tools
• According to Cursor, 1 billion generated lines of code accepted a day, which represents about a third of the overall accepted lines
• 40% increase in builds
• 15% increase in commits
• 25% increase in completed development tasks

AI-assisted coding is not going anywhere.
But neither is the need for reliability, on the contrary.

In brief, developers do more thanks to GenAI. But the downside is that they are losing familiarity with the code base and tend to take less and less responsibility for it since it’s generated. From an SRE point of view, it means that guardrails have to be hardened now more than ever. In other words, SRE basics are more and more important — progressive roll-out processes, observability and alerting, etc.

---

Do you want to attend SRECon 2026 as part of the Criteo team? Easy, we are hiring! 😉 Became one of us