Operations | Monitoring | ITSM | DevOps | Cloud

While most on-call schedules are built to represent regular rotations, often on a weekly basis, not all of your on-call needs require the same coverage every week. We’ve added Custom Shifts to the Shift-Based Schedules for maximum flexibility. Custom shifts are a feature of our new Shift-Based Schedules. With Custom Shifts, your team can cover ad hoc needs for special events, major deploys, Failure Fridays, gamedays, or whatever comes up that needs some extra coverage.

Ask any engineering leader how AI has changed their team, and you'll get an optimistic answer. Ask them to prove it with a number, and most go quiet. That gap is the story of 2026. Individual engineers are faster than they've ever been. Teams, in a lot of cases, aren't. We talked to our own engineering team, the people who've spent the last year building and shipping Upsun Dispatch and living through exactly this shift, and the same tension came up again and again.

Enterprise workflow automation can deliver faster resolution and ultimately more time back for IT teams. But not every workflow is ready to automate on day one, is it? This is where many automation programs stumble. Teams often start with signals like the most visible problem or the workflow that creates the most frustration. These are useful signals, but they’re not enough on their own. The best automation candidates are usually repeatable, measurable, and have clear inputs and outputs.

AI agents fail differently from the software we spent the last two decades learning to monitor. We hear some version of the same story from teams shipping agents to production: an agent starts producing wrong answers. Not obviously broken: confident, well-formatted, plausible wrong. The logs are clean, latency looks healthy, and error rates sit at zero. Nothing flags a problem. A user eventually does.

‍Teams building agents have converged on something that looks a lot like the software development lifecycle, but reshaped around a system whose output isn't deterministic: prototype an agent against a framework, evaluate it against a dataset of expected behavior, deploy it somewhere real, observe how it behaves against live traffic, and feed what you learn back into the next prototype. Call it the agent development lifecycle (Agent DLC).

‍ Here is a story platform engineering teams know by heart: developers find a shiny new tool, start building at a breakneck pace, and before you know it, the organization is drowning in a massive wave of unmanaged components. Right now, that exact story is playing out with generative AI.

As the size and complexity of their relational database workload grows, every company eventually goes through the process of off-loading work on a read replica. It comes with lots of benefits, but at a cost of increased complexity. This article is about how we dealt with that, a lot of learnings, and some useful techniques. incident.io is an incident management product relied on by thousands of customers to be the thing that supports them through anything from a minor blip to a full outage.

You’ve decided to step up your logging game and start sending more valuable, structured logs that you can query, aggregate, and use for debugging in production. Go, you! Now, uh, how do you actually write them? We’re not going to spend much time on what you should log. We’ve covered that already, a few times before. What we will be covering is how to actually write those logs, answering questions like: What makes a log structured is not just pairing messages with arbitrary JSON objects.

In our first series post, The New Software Creator, we mapped out a structural shift in the industry: AI is turning non-technical team members into creators of software. In our second post, When Anyone Can Build Software, Deployment Governance Is What Keeps It Safe, we argued that deployment is the single control layer that can secure this explosion of output without choking innovation.

Autovacuum is one of those Postgres background jobs that quietly keeps your database healthy. It cleans up the dead row versions that every UPDATE and DELETE leaves behind, and it keeps the database away from a hard transaction-ID limit that would take it offline. Most of the time you don't think about it, because it just works.