The Teammate That Tells You It's Broken Before You Notice | Crescentic
July 9, 2026Reading time: 9 min
The Teammate That Tells You It's Broken Before You Notice
Part 1 of our build-in-the-open series: the teammate that speaks first. How Pulse closes the gap between the moment something breaks and the moment someone notices.
Murtaza - Senior Product Engineer
Part 1 of our build-in-the-open series. Last time we introduced the whole AI squad; this one is about the teammate that speaks first.
It was a Wednesday afternoon and I was deep in something else when Slack lit up in a channel I don't sit in. Not a person pinging me. A message that started with the word failed. Our main branch had just broken. A deploy had gone out, a check had gone red, and the thing telling me about it wasn't a teammate who happened to notice. It was Pulse.
Nobody asked it to look. Nobody was watching the pipeline with a coffee, waiting. It saw the branch go from fine to not-fine and it said so, in the room where the people who could fix it already were, moments after it happened. I read it, pinged the right person, and it was handled before it became the kind of thing a client finds first.
That last part is the whole point of this post. The expensive failures in most businesses aren't the loud ones. They're the quiet ones, the thing that broke at 2 p.m. that nobody clocks until 5, or until the customer clocks it for you. The gap between it broke and someone noticed is where the cost lives. Pulse's job is to close that gap.
It speaks first
If you read the last part, you have met Pulse already. It's one of three AI teammates that live in our Slack, and its beat is the projects: what shipped, what stalled, what broke. Last time I described it as the thing that posts a summary every morning. True, and that is the calm, boring 90% of what it does.
But a summary is still something you sit down and read. The part that changed how the studio feels is the other 10%, the moment Pulse stops waiting for morning and interrupts you, because something is wrong right now and morning is too late.
A chatbot waits for a question. You open it, you ask, it answers. Pulse is the opposite shape. Most of the time it is silent. Then, unprompted, it puts a hand on your shoulder. You already know what it's like to ask software a question. It's a genuinely different feeling to have software come find you.
Here's where I want to be precise, because "AI that monitors everything" is a promise that usually means "AI that pings you about nothing useful."
Pulse interrupts you for exactly one kind of event: a build or a deploy failing on the branch that ships. Not a pull request. Not someone's half-finished experiment on a side branch. Not a passing build, not a flaky test that sorted itself out on the retry. When the branch your customers actually get breaks, and only then, an alert lands in the project's channel.
That narrowness is not a limitation I'm apologizing for. It's the feature. An alert you can trust to mean "drop what you're doing" is worth ten alerts you have taught yourself to swipe away.
The hard part was making it shut up
I'll admit I expected the alerting to be the easy bit. Something breaks, send a message, how hard can it be. The hard part, it turned out, was the silence.
The first honest version of a monitor is unbearable. A build can fail, get retried, and fail again, three times in five minutes. GitHub can deliver the same event to us twice. A branch that's broken stays broken until someone fixes it, and a naive alerter will happily remind you of that every few minutes, like a smoke alarm with a low battery. Within a day you would mute the channel, and a muted alarm is worse than no alarm, because now you believe you're covered.
And that failure is human, not technical. Nobody swipes an alert away on purpose. Attention just wears down. A signal you see many times a day stops registering as a signal, however conscientious you are, and no amount of willpower fixes it, because the problem was never willpower. This is the one place software genuinely has us beat. Pulse has nothing wiser to say than a good engineer would. It simply never gets tired, and never learns to tune itself out.
So most of the engineering went into restraint. Pulse alerts on the transition, the moment a branch crosses from passing to failing. It's the difference between a car that chimes once when you leave a door open and one that chimes the whole time the door stays open. One tells you something. The other becomes noise you stop hearing. A build that's still failing an hour later is not news; it's the same news, and it stays quiet. Duplicate deliveries get dropped. There's a cooldown floor so a thrashing pipeline can't spam the room. Each repository keeps its own little memory of "have I already said this," so one noisy project can't drown out the others.
The result is a channel where a message from Pulse actually means something. It has earned the right to interrupt you, by spending most of its existence saying nothing. If there were one idea from this whole series I would want a non-technical owner to take away, it's that: the value of an alerting system is mostly in what it declines to send.
There is a practical version of that, if you ever go to build one. Don't start from what you could detect, because almost anything can be detected. Start from a harder question, asked of every candidate alert: is this worth spending a person's attention on, every single time it fires, forever? Most don't survive it. The few that do are the only ones worth wiring up. Attention is a budget that doesn't refill, and the whole craft is spending it like you know that.
The calm 90 percent
Underneath the alerts is the quieter habit. Every morning, before most of the team is online, Pulse posts a digest for each active project: what moved yesterday, what's open, what's waiting on someone. On Friday afternoon it posts the week in review. I don't trigger these. They arrive because it's morning, or because it's Friday.
It's the difference between walking into a room already knowing where things stand and spending the first hour of your day reconstructing it from twelve browser tabs. Nothing dramatic. Just a floor under the day.
What the watching costs
Here's the number people don't expect, so I'll put it plainly. The alerting, the part that watches around the clock and pings you the second the branch breaks, costs effectively nothing to run. It never calls an AI model. Deciding "a build failed on main, is this new, should I speak" is a handful of fast, deterministic checks. No reasoning, no tokens, no bill.
The AI only wakes up for the writing. When Pulse composes a morning digest, that's a model doing actual work, and it costs about half a cent. Call the whole day of summaries a rounding error you would struggle to notice on a statement. The 24/7 watchdog is free; you only pay, a fraction of a cent at a time, when there's prose worth generating.
I like that split because it kills the scariest version of the question. "You have an AI watching your systems all day, what does that cost?" Nothing, until it has something to say. And then, pennies.
Where it gets thin
Let me stay honest about the seams, the same way I tried to last time, because a build log that only shows the wins is an ad wearing a lab coat.
The restraint I just bragged about cuts both ways. I tuned Pulse to only shout when something clearly, cleanly breaks. That means it's excellent at the sharp failures and blind to the slow ones. A problem that never trips a hard red check, a thing that just gets quietly worse, won't set it off. The textbook version is a site that passes every health check with a cheerful all-clear while a customer sits there staring at a checkout button that won't load. Every light green, and the thing is still broken. Pulse watches the build, not the customer's screen, so that's a gap it would miss too. It's a smoke detector, not a doctor. It catches fires, not fevers.
And it only watches what we pointed it at, which is our own code. Client work that lives on other systems is simply outside its view. The morning picture it paints is real, but it's the picture of one room, not the whole building. Knowing that is the difference between a tool you trust appropriately and one you trust blindly.
This isn't a code thing
Strip the words "branch" and "deploy" off what I described and you're left with a pattern almost any operation can use: watch quietly, and interrupt a human only at the moment a thing crosses from fine to not-fine.
A logistics team already lives in a tracking dashboard where every shipment blinks for attention, which is exactly why the one that actually slipped is the one you miss. The move is to go dark on the routine and speak only on the exception that needs a person.
A clinic doesn't lack alerts. It drowns in them. Electronic records fire so many pop-ups that staff learn to click past them, and that fatigue is a known patient-safety problem, not a hypothetical. The win there isn't one more notification. It's the discipline to send far fewer, so the ones that land are believed.
An agency usually learns a client's site is down from the client. Hearing it the second it happens, and only then, is the difference between a save and an apology.
Same move every time. Stay silent through the normal. Speak once, clearly, on the transition that matters.
What's next
The next posts keep opening the hood, one teammate at a time, and eventually go straight at the question every owner actually asks, which is how you keep something like this reliable and safe rather than a liability. Not a pitch. A build log, with the receipts attached.
If you read the opening of this and thought about the last time you found out too late that something had broken, that wasn't an accident. That's the gap worth closing.
We're building this in the open. Follow along for the next teammate, and if you're already picturing it in your own shop, say hi.
Technical readers: how the alerting stays quiet, how the webhooks are deduplicated, how the cron summaries stay honest and cheap, it's all in the appendix.
