Insights on scheduling, productivity, and building open software

Security testing hasn’t kept pace with how software is built or how it’s attacked. While development cycles have accelerated and AI-powered attackers can probe systems continuously, most security practices still rely on periodic assessments and slow remediation. The result is a widening gap between when vulnerabilities are introduced and when they’re discovered or fixed. In our recent analysis of autonomous AI-driven pentests across production systems, that gap becomes impossible to ignore: modern applications aren’t just vulnerable, they’re continuously vulnerable.

Guest post by Huzaifa Ahmad, Founder, Hex Security

On June 22, 2026, our primary asynchronous task and queue management partner, Trigger.dev, suffered a catastrophic, multi-region cascading failure. Because our core platform infrastructure relies heavily on their engine to process background jobs, webhooks, and critical workflows, this upstream failure immediately created a high-severity incident for our own application.

Trigger.dev has published their own transparent engineering breakdown here: Trigger.dev Incident Report (June 22, 2026). Below is the aligned breakdown of how their infrastructure failure directly mapped to our internal engineering timeline and how we engineered our way out of a total blackout.

We moved Cal.com's production codebase from a public repository to a private one. The public repository is now calcom/cal.diy, known as Cal.diy, the open-source, self-hostable, community-driven version of Cal.com.

Here's what changed.

On Tuesday, January 27th, we experienced a production incident that caused degraded performance across the platform and full downtime for some enterprise customers with high-volume event types.

The incident started as elevated database load, appeared resolved, and then revealed secondary failures in downstream systems. This post explains what happened, how we confirmed it, and what we changed as a result.

Slow CI is one of those things that grinds engineering team’s gears. Engineers wait longer for feedback, context-switching increases, and the temptation to batch changes grows, which only makes things worse. We spent a few weeks optimizing our GitHub Actions workflows and cut our PR checks from 30 minutes to 5 minutes. That’s an 83% reduction in wait time, achieved without sacrificing any test coverage or quality gates.

There wasn’t a single magic fix. We looked at where time was actually going and applied three principles: smart job dependencies, aggressive caching, and test sharding. Here’s what we learned.

On November 14th, we launched an updated design for the bookings page but quickly encountered usability issues. In this post, we share what we learned from the incident and the steps we're taking to improve our release process.

We are building infrastructure that must almost never fail. To achieve this, we move fast while shipping amazing quality software with no shortcuts or compromises. This document outlines the engineering standards that will guide us through 2026 and beyond.

A deep dive into how we detected, analyzed, and optimized poorly performing algorithms in a real production codebase.