Operations | Monitoring | ITSM | DevOps | Cloud

Custom shifts for one-off requirements or complex schedules

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.

What engineering teams are getting wrong in 2026

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.

How to Test IT Workflows for Enterprise Workflow Automation

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.

Introducing Harness AgentTrace: An Observability and Guardrail Framework for AI Agents | Harness Blog

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.

Introducing AI Agent Deployment in Harness Continuous Delivery | Harness Blog

‍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).

Don't add a read replica until you've read this

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.

How to structure a log

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.

Security at Scale: What Changes When Everyone Can Deploy using AI

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.

Let's break autovacuum in Postgres: reproducing failures to make it observable

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.