How to Find Old Decisions in Slack (When Search Isn't Enough)
How to find old decisions in Slack when keyword search fails. Why decisions vanish, why decision logs don't stick, and what a decision-aware system looks like.
By Ellis Keane · 2026-03-14
Quick: where did your team decide to use webhooks instead of polling? Not what you decided – where is that decision written down right now, in a place someone joining next month could find it?
If you're anything like us, the honest answer is somewhere between "a Slack thread, probably" and "I think it was in #eng-backend, maybe three weeks ago, and I'm pretty sure it involved two or three people but I genuinely cannot remember which ones." Which is a fascinating state of affairs when you think about it, because the decision itself was important enough to change how the entire system works, but apparently not important enough for anyone to write down in a place that isn't a stream of consciousness organized by timestamp. And that, in a nutshell, is the problem with trying to find old decisions in Slack – the information is all there, it's just not organized in a way that lets you retrieve it as a decision.
I've been poking at how to find old decisions in Slack for a while now, and the more I dig into it, the more I think the core issue isn't discipline or habit or any of the other things people blame. It's architectural. Slack's search was built to find messages, and decisions aren't messages – they're meaning that happens to be expressed through messages, which is a distinction that sounds pedantic until you've spent twenty minutes scrolling through search results trying to figure out which of seventeen mentions of "webhooks" was the one where your team actually committed to using them.
How Slack search actually works (and where it breaks)
Let's be precise about this, because "Slack search is bad" isn't the right diagnosis – Slack search is actually quite good at what it does. The problem is that what it does and what you need it to do when you're looking for a decision are two fundamentally different things.
Slack indexes messages as text with metadata: timestamp, sender, channel, and (if you're on a paid plan) the full thread context. When you search for "webhook," Slack faithfully returns every message containing that word, ranked by some combination of recency and relevance. You can narrow things down with search operators – in:#eng-backend from:@sarah before:2026-02-15 – but all you're doing is filtering the same flat list of messages by metadata. This is keyword retrieval, and for finding a specific message you half-remember, it works fine.
But a decision isn't a keyword. A decision is a relationship between a question, a set of options, a set of people, and a moment where the group converged on one option. The actual text of the decision might be "yeah let's just do webhooks, the polling approach is eating our rate limit" – which is conversational, contextual, and only meaningful if you already know the thread it appeared in. Or it might be "that works, let me prototype it," which contains zero keywords related to the technical decision it represents.
This is the architectural mismatch: Slack stores messages chronologically and retrieves them by keyword. Decisions are semantic (they're about meaning) and relational (they connect to tasks, people, and outcomes). You're asking a chronological storage system to perform semantic retrieval, and it can't, because it was never designed to. The gap between "searchable" and "findable" turns out to be enormous – every message in your Slack history is technically searchable, but that doesn't mean the decision you need is findable in any practical sense.
"Slack has created one of the largest repositories of organizational decision-making in history, and almost none of it is retrievable as decisions – every word perfectly preserved and almost entirely unfindable." – Ellis Keane
What happens when you try to find old decisions in Slack
Here's what the mismatch looks like in practice. Say your team decided three weeks ago to switch from polling to webhooks for a GitHub integration. You remember the discussion happened in #eng-backend and involved a few engineers. So you search for "webhook" in that channel.
What comes back: every message that has ever mentioned webhooks in #eng-backend. Bug reports from six months ago. Someone asking a question about webhook retry logic in a completely different context. A link somebody shared to a blog post about webhook best practices (which, in a beautiful piece of irony, probably ranks higher in the search results than the actual decision it's sitting next to). The decision itself – a reply in a thread where someone said the polling approach was hitting rate limits – is buried somewhere in page three, looking exactly like every other message around it.
And that's the scenario where you remember roughly what words were used. Half the time, decisions use language that's so contextual it might as well be encrypted. "Let's go with option B" doesn't contain the word "webhook" at all, even though option B was webhooks. "That works, let me prototype it" doesn't even contain the word "option." The actual moment of decision is often the shortest, least keyword-rich message in the entire thread, because by that point everyone in the conversation already has the context and they're just confirming alignment.
I find this genuinely interesting as an information architecture problem (well, interesting and also mildly infuriating when you're the one doing the searching). Slack has created one of the largest repositories of organizational decision-making in history, and almost none of it is retrievable as decisions – every word perfectly preserved, and almost entirely unfindable.
Why decision logs are a graveyard with better signage
The standard advice, if you go looking for solutions, is to keep a decision log. A Notion database, a dedicated Slack channel (the irony of which apparently escapes the people recommending it), a wiki page – some single place where decisions get recorded as they happen.
We tried this. It lasted about six weeks. The first two weeks were great – everyone was committed, entries were detailed, the log was genuinely useful. By week three, entries started getting spotty. By week five, one person was still updating it, writing things like "decided thing about auth" with no links, no context, and no indication of who was involved or what the alternatives were. By week six we quietly stopped pretending.
The problem isn't that our team lacks discipline (I mean, maybe, but that's not the relevant issue here). The problem is that decision logging imposes a tax at exactly the wrong moment. You've just had a productive discussion, you've reached alignment, someone's ready to start building – and now you need to pause, open a different tool, write a summary, tag the relevant people, and link back to the original conversation. That's three to five minutes per decision, and for a team making five to ten meaningful decisions a day across channels and threads, the overhead compounds into something that nobody wants to own.
And the system only works at 100% compliance. A decision log with 70% of decisions is worse than no log at all in some ways, because now you're checking two places and trusting neither. You look in the log, the decision isn't there, so you go search Slack anyway – and you're back where you started, except now you've also wasted two minutes checking the log first.
Decisions aren't events – they're gradients
Part of why manual logging fails is that it assumes decisions are discrete, identifiable moments. In reality, most decisions emerge gradually through conversation, and the "moment of decision" is often genuinely ambiguous.
Consider how a typical engineering decision actually unfolds. Someone raises a concern in a Figma comment: "this interaction pattern might not work on mobile." An engineer replies in a Slack thread, tagging the original comment: "yeah, I looked into this – the component library doesn't support it." A designer suggests an alternative approach in the same thread. The engineer says "that works, let me prototype it." Two days later, a PR goes up implementing the alternative, and the Linear issue gets updated.
Where was the decision made? Was it the Figma comment that surfaced the problem? The Slack thread where the alternative was proposed? The moment the engineer said "that works"? The PR that implemented it? In practice, the decision was distributed across all four of those moments, spanning two tools and three days. It wasn't an event you could log – it was a gradient that resolved into an outcome, and the only reason we know a decision was made is that the code changed.
This is (I think) the part that most "decision tracking" advice gets wrong. It treats decisions as things you capture, like writing down a phone number. But most real decisions are things you reconstruct – you look at what changed, trace backwards through the conversations that led there, and piece together the reasoning after the fact. Which means the system you need isn't a log. It's a graph.
What a graph gives you that a log can't
A graph connects signals across tools and time. Instead of someone manually writing "we decided to use webhooks because of rate limits," the graph links the Slack thread where rate limits were discussed, the Linear issue that tracked the integration work, the PR that implemented webhooks, and the people who were involved in the conversation. The decision isn't recorded – it's reconstructable from the connections between things that were already happening.
The practical difference shows up in a specific scenario. Three weeks after the webhook decision, a new engineer joins and asks: "why are we using webhooks instead of polling for GitHub? Polling seems simpler." Without a connected system, someone says "oh, we decided that a while ago," nobody remembers which channel, someone spends fifteen minutes searching Slack, and they either find it or (more likely) reconstruct the reasoning from memory, which is risky because memory is unreliable and the original reasoning was almost certainly more nuanced than what anyone remembers three weeks later.
With a graph, the engineer looks at the GitHub integration task. Every signal that touched that task is linked: the original discussion about rate limits, the thread where polling vs. webhooks was evaluated, the PR that implemented the change. The full decision trail, end to end, without anyone having searched for anything and without anyone having logged anything.
The gap isn't between "good search" and "bad search" – it's between retrieval by keyword and retrieval by relationship. Decisions are defined by their connections to tasks, people, and outcomes, not by the words used to express them.
The costs that don't show up on any dashboard
I'm honestly skeptical of anyone who claims precise numbers for soft costs like these (the "teams waste X hours per week" genre of statistics always feels like it was reverse-engineered from a desired conclusion), but here's what we've observed in our own team.
The most obvious cost is re-litigation – when nobody can find the original decision, teams just re-open it, sometimes because people genuinely don't remember and sometimes because a new team member has legitimate questions that nobody can answer with specifics. We were re-litigating settled questions regularly before we had a way to trace decisions back to their source, and each re-litigation carries its own overhead: the meeting time, the emotional fatigue of arguing something you're pretty sure was already resolved, the nagging suspicion that the original reasoning was more nuanced than what anyone remembers.
The subtler cost is what happens during onboarding. Every "why was it done this way?" question from a new team member interrupts someone who was there for the original decision, and the answer gets reconstructed from memory each time someone asks, drifting slightly further from the original reasoning with each retelling – like a game of telephone, except the phone is enterprise software and the message is "why does the architecture work this way." And there's a credibility gap that compounds over time: "we went with webhooks" carries less weight than "we went with webhooks because polling was eating 40% of our GitHub API rate limit and we were hitting throttling during peak hours." The reasoning is what allows future engineers to evaluate whether a decision still holds under changed circumstances, and that reasoning is sitting in a Slack thread somewhere, perfectly preserved and practically invisible.
Stop losing decisions to Slack scroll. Sugarbug traces the full decision trail – from the Slack thread to the Linear issue to the PR – automatically.
Q: Why is it so hard to find old decisions in Slack? A: Slack stores messages chronologically, not by meaning. A decision buried in a thread looks identical to any other reply – Slack's search can match keywords, but it can't distinguish "we decided to use Redis" from "should we use Redis?" without reading the full conversational context. The more time passes, the harder it gets, because you lose the contextual cues (who was involved, what channel, what week) that make search viable in the first place.
Q: Does Sugarbug track decisions made in Slack automatically? A: Yes. Sugarbug classifies incoming signals from Slack and other connected tools, identifying decision-like patterns – threads that reference tasks, involve assigned people, and result in status changes or PRs. These get linked to the relevant task in the knowledge graph, so you can trace the decision trail from the task rather than searching through Slack history.
Q: What's the difference between a decision log and a knowledge graph for decisions? A: A decision log requires someone to manually record each decision as it happens – notice it, pause, summarize it, tag it, link it. A knowledge graph infers decisions from signals flowing through your tools and links them to tasks, people, and conversations automatically. One depends on consistent discipline from every team member; the other runs in the background from the activity already happening.
Q: Can Sugarbug surface decisions from tools other than Slack? A: Sugarbug connects to Slack, GitHub, Figma, Linear, Notion, email, and calendars. Decisions often span multiple tools (a Figma comment leads to a Slack thread leads to a PR), and the knowledge graph links signals across all connected surfaces. You see the full trail regardless of which tool the conversation started in.
Q: How is this different from just using Slack's built-in search? A: Slack search finds messages that contain specific keywords. A knowledge graph finds the relationships between messages, tasks, and people. When you're looking for a decision, you're rarely searching for a word – you're searching for the moment where a team chose one approach over another, and that moment is defined by its connections to other signals, not by the words used to express it.
---
If decisions keep vanishing into your Slack history, the problem isn't Slack – it's that no system is watching for the moments that matter and connecting them to the work they shaped. That's the gap we're building Sugarbug to fill.