PulseSync
Real-time incident command for platform teams.
An operations room for on-call teams, shaped from two weeks of interviews and built to stay calm on the worst night of the year.
- 99.99%
- Uptime
- Under 40ms
- Live update latency
- 1,240
- Workspaces on it daily
How it started
It began as a conversation, not a brief.
A platform team came to us with a chat channel, a spreadsheet and a lot of missed handovers. Nobody could say who was on an incident, what had already been tried, or what the timeline looked like afterwards. We spent two weeks sitting in on calls before we drew a single screen, and what we heard changed the product: the hard part was never the alerting, it was keeping everyone looking at the same version of the truth while the pressure was on.
What we did
- Product discovery
- UX and interface design
- Data architecture
- Production engineering
Product decisions
What to build, and just as importantly what to leave out.
A live operations room where on-call teams see every signal, claim an incident and write the timeline as it happens.
One room, one truth
Everything about an incident lives in one place — signals, the person who claimed it, the decisions and the timeline writing itself as people work. Nobody has to reconstruct what happened the next morning.
Built for people who are typing fast
Every action has a keyboard path, and nothing blocks on a spinner. Claiming, escalating and noting all appear instantly and reconcile in the background, because a half-second of doubt at 3am costs more than it sounds like.
What we deliberately left out
No dashboards nobody reads, no configuration screen with forty switches. We cut the whole reporting section from the first release and shipped a single review page instead. It is still the second most used screen.
How it is built
The part nobody sees, which is the part that has to hold.
The same engineers who designed this still run it. Here is how it is put together and why we made those calls.
Live state that survives a bad connection
Updates stream over persistent channels with a per-incident sequence, so a client that drops off and comes back replays what it missed rather than guessing. Two people acting at the same moment resolve to one agreed order.
Access that matches the org chart
Workspaces, teams and roles are enforced in the database itself, not in the interface. A member of one workspace cannot read another's incidents even if a request is crafted by hand.
Ready for the worst night
The read path is separated from the write path and the timeline is append-only, so a spike in traffic slows nothing down and nothing is ever overwritten. Restores are rehearsed, not theorised.
- Availability
- 99.99% across the last twelve months
- Recovery
- Restore rehearsed and timed every quarter
- Access control
- Enforced in the database, per workspace
- Support
- We are on call for it, not just the customer
Where it is now
What it does for the people using it.
- Incident handovers went from a chat scroll to a written timeline nobody has to assemble afterwards.
- Live updates land in under 40ms, so two people never act on different information.
- It has stayed up through every incident it was built to handle.
Building something like this?
Bring us the idea, or bring us what you already have.
We can build it with you from nothing, or look at what exists today and tell you what to fix, what to build next and what to leave out.