Operations | Monitoring | ITSM | DevOps | Cloud

I don't write SQL. Not by hand anyway. That might sound like a confession, but it's true of most analysts (and engineers) now. In the 9 months since joining incident.io I have built headcount models for hiring decisions, a Slack bot for assigning new customers, guidance for our AI data analyst, and a couple of internal web apps. If you asked me which of those counted as "analysing data", I'd struggle to say. A lot of that comes down to the "commercial" part of the job title.

Our cloud agents now test mobile pull requests on cloud simulators and leave screenshots and a recording behind. The agent collects the evidence, and a person decides whether the change is right. More and more of the code in that app is written by coding agents. Of the 144 pull requests opened against it in the last two weeks, 99 were opened with Claude Code or Cursor. The agents are good at writing the change. What they couldn't do was show it to you.

At incident.io we are huge fans of Postgres; we've written about it a lot over the years, including how to choose the right indexes and how we're proud of being boring (The Pet Shop Boys). We use Postgres as our primary transactional database, which as of today has ~900 tables, and counting! The vast majority of our codebase does something along the following lines: read some data from Postgres, execute some business logic, then write that data back to Postgres. It is not, however, always that simple.

At incident.io, we've spent the last two years building Investigations, our AI SRE. When you get paged, it starts investigating straight away, looking across your telemetry, recent deploys, past incidents, docs and code, and posts what it's found in your incident channel (or on your phone, if it's 2am and you're still deciding whether you need to get out of bed). By the time you open your laptop, you're starting at step six of triage rather than step one.