Skip to main content
Alert channels rarely get the attention they need. Engineers either tune them out and miss the warning that mattered, or spend hours keeping up and still miss things. Almost nobody finds time to prune the noisy ones, so the channel only gets louder. An Alert Worker triages and prioritizes every single alert so that you don’t have to, and escalates the ones you should actually focus on.
Alert Workers are in public beta. Contact your Traversal representative to gain access.

What happens when an alert fires

Every time an alert fires, the Worker looks at it, investigates, and replies in that alert’s thread with what it found and what it recommends. It also reacts to the alert with its assessment, so you can scan the channel by urgency and see which alerts are a critical issue, which are technical debt worth addressing at some point, and which are just a noisy alert that needs its definition fixed. Reply in the thread to push back or ask for more detail. Nothing rests on how often an alert fires — a verdict comes from your current telemetry, prior investigations, linked tickets, and whatever your team already said in earlier threads. Alert channels run at high volume, so a Worker is built to be token-efficient: when a fire clearly repeats something it has already worked out, it says so and links to that earlier work rather than investigating twice.

A familiar disk alert closed out with the threshold change that removes all 31 of its false fires — and a replication-lag alert escalated the moment it crosses the paging threshold.

The scratchpad

The scratchpad is the Worker’s up-to-date synthesis of the whole channel, written for the engineer who just came on call: what needs action now, what’s recurring and why, the known causes and prior fixes, and where the alerts themselves are worth improving. Open the Worker from the Workers console to read it. Use private chat for the follow-ups — why did this fire, is it getting more frequent, did other alerts share the same cause, how should we update this definition — without adding channel noise.

Steer it in plain English

Set policy with custom instructions rather than regex or a rules file:
Schedules cover shift handoffs and alert-health reviews. Because the Worker has been in the channel the whole time, a handoff is what actually happened and what’s still open — not a digest of subject lines.

FAQ

Noise filters mostly count how often an alert fires. An Alert Worker investigates why it fired and grounds its verdict in real evidence — your telemetry, past investigations, linked tickets, and what your team already said about it in the thread. Most alerts aren’t meaningless noise; they’re real problems, unknowns, or misconfigured rules, and the Worker tells them apart.
No. An Alert Worker triages and explains — it posts its reasoning and suggests fixes. It never changes your alerting, paging, or routing. You stay in control of what happens next.
Every response goes in its alert’s own thread, never the main channel, so the channel reads exactly as it did before — just with a verdict on each alert. When one monitor double-posts the same fire, the Worker responds once in full and links the duplicates to it.
Yes. Reply with @Traversal in the thread to add context and steer the analysis. The Worker will re-investigate when what you’ve told it changes the picture.