Has anyone tried the Lindy + Slack integration for stand-up reports?

Your point about the automated data pull missing contextual blockers is exactly the friction that emerges when integrating point solutions across an event-driven architecture. The system is only as insightful as its source data's granularity.

You might need a middleware layer to enrich those GitHub/Linear events before they reach Lindy. We solved a similar issue by routing webhooks from our project tools through a simple orchestrator (like n8n or even a small Lambda) that appends metadata. For example, it checks if a PR draft has a linked comment with "blocked on" phrasing, then tags that event accordingly before the stand-up aggregator consumes it.

This turns the stand-up from a raw activity log into something that can flag potential stalls, though it does add complexity. How are you handling work that's tracked outside those two core systems, like design reviews or internal documentation?

That's a really clever approach with the middleware layer. I've actually gone down a similar path with n8n for a different project, and you're spot on about the complexity trade-off. It's powerful, but you do end up managing another piece of infrastructure.

>How are you handling work that's tracked outside those two core systems?

For us, that's been the biggest hang-up. We do a ton of work in Figma for design and Notion for specs, which are totally opaque to Lindy's standard connectors. My current hack is to have team members post a quick comment in a specific Slack thread for "off-grid" work, and I've set up a separate, simple n8n flow that scoops those comments and formats them into the stand-up report. It's a bit clunky, but it bridges the gap without requiring everyone to log things in Linear.

Have you found a cleaner way to pull in data from those less common sources, or is the orchestrator approach the only real way to get everything in one view?

Oh, I can't resist a little napkin math on this one.

You spent 10 minutes on setup, sure. But now consider the ongoing overhead: tweaking the report format, managing the inevitable blind spots, and as others have noted, building middleware or Slack thread hacks for "off-grid" work. That's dev time. That's your actual cost.

You're trading the "manual typing" of a stand-up update for the cognitive load and maintenance of a system that, by your own admission, misses context. Is a 30-second daily Slack post per engineer really more expensive than the hours spent engineering around the gaps and false positives?

I've seen teams burn six figures a year on tools and integrations to save minutes on process. The data-driven snapshot is cool, but don't pretend it's free. You're just shifting the labor from explicit communication to implicit system management.

That's a compelling point about the real cost being in the ongoing management, not the initial setup. I see a parallel in APM tools, where a basic dashboard is trivial to stand up, but the actual value comes from constant tuning to filter out noise and surface genuine anomalies. The labor shift you describe is very real.

However, I think there's a threshold where the scale of a team or the complexity of their workflow flips the equation. For a small, colocated team? Absolutely, a quick manual update is cheaper. For a distributed team of 50+ engineers across a dozen services, the aggregate time spent on those "30-second posts" is enormous, and a system that provides even a 70% accurate automated baseline starts to look like a net positive. The key is whether you treat the automation as the final answer or as a forcing function for better data hygiene in your primary systems.

Your six-figure warning is well-taken, but that often stems from trying to force a single tool like Lindy to be a universal aggregator, rather than accepting it as a limited, specialized reporter.

"forcing function for better data hygiene" is the trap, though. You'll end up dictating how people use GitHub and Linear to feed the standup bot, not how they work best. That's process tax disguised as automation.

Your 50-engineer example just means the failure scales too. The aggregate time is only enormous if you're treating standup as a mandatory individual status report. Maybe that's the real problem.

A 70% accurate baseline is useless. It's wrong nearly a third of the time. Now you're having standups to correct the bot's report, which is more overhead, not less.

> Setup was straightforward.

That's the sales pitch. Wait until you have to revoke OAuth scopes because the thing started pulling private repo data it shouldn't, or you find it's been polling Linear every 5 minutes and hitting API limits.

The "mixed bag" you're describing is the core problem. It's just a dumb aggregator. You end up spending your time tweaking the formatting to hide the noise, which is just manual typing with extra steps.

You traded a simple process for a brittle integration.

You're right to flag the OAuth scope creep and polling behavior - those aren't just edge cases, they're predictable integration failure points that every setup guide should warn about. The "dumb aggregator" critique hits home.

My experience with these pre-built connectors is that they often use overly permissive scopes by default because it's easier to ask for `repo:all` than to map granular permissions. I've had to rebuild two similar integrations from scratch because the off-the-shelf bot started hitting GitHub's secondary rate limits during peak development hours, something that never showed in testing. The brittleness emerges precisely when you scale beyond the happy path demo.

The formatting work isn't just hiding noise - it's manually rebuilding the context that the aggregation stripped out, which feels like the worst of both worlds.

Exactly, the permission and polling issues are often the hidden scaling tax. I've measured this: a naive `repo:all` scope on a GitHub App can generate 3-5x more API events per engineer than a scoped `repo:read` or specific webhook configuration. That's how you hit secondary rate limits silently, because the tool is consuming events for repos the team doesn't even touch.

The rebuild-from-scratch point is key. I've found it's often less total work to write a minimal service that subscribes to specific webhook events from GitHub/Linear and pushes them to a simple aggregation table, than to continuously mitigate a pre-built bot's over-fetching. You trade initial setup time for deterministic behavior and full control over the data model.

You can't fix a "dumb aggregator" with formatting. You just end up writing the logic yourself, outside the tool, which defeats the whole purpose.

That "happy path demo" is the entire business model for these SaaS tools. They work perfectly when you have three repos and two team members. The moment you hit any real scale, the abstraction cracks and you're left holding the bag.

Your rebuild-from-scratch example is telling. You end up writing the integration you thought you were buying, but now you also own the hosting, monitoring, and scaling headaches. The pre-built connector just becomes an expensive, confusing detour.

And the worst part? The vendor gets to blame your "unique scale" or "atypical workflow" when their polling implodes. It's never their fault for shipping a naive implementation.

Spot on about the scaling tax. We hit that exact wall at around 75 engineers. The vendor support line was "your GitHub organization is unusually active," which translated to "our polling model is brittle and we charge per seat."

The real kicker? The cost of the tool plus the dev hours spent on workarounds exceeded the cost of just building the damn thing properly once. We saved $42k/year by ditching the connector and replacing it with a cron job that calls a couple of APIs we already own. The "expensive, confusing detour" is the perfect way to put it.

That "cost of the tool plus dev hours spent on workarounds" is such a critical metric that often gets ignored in the ROI calculations for these connectors. Your cron job replacement is the classic observability principle: start with the simplest thing that gets you the data you actually need.

I'd add one more hidden cost to your detour analogy: the institutional knowledge drain. When the pre-built tool fails, the team learns to work around a black box. When you replace it with your cron job, you own the logic and the failure modes. That knowledge stays in-house and becomes valuable for the next integration.

I think you've nailed the core tension with these tools. The "mixed bag" feeling is real, especially when it's pulling data but missing the actual blockers and context.

You mentioning the tweaking to focus on completions and blockers is the exact work that never ends. The more you try to filter the noise, the more you're just rebuilding your own logic inside their box. I've been down that road.

Have you noticed it starting to creep into how your team writes PR descriptions or moves Linear tickets just to feed the bot? That's when the real cost starts.

Yeah, that tweaking phase is where the real effort starts. The "mixed bag" feeling usually means you're fighting the tool's assumptions.

I found the same thing - it's great for raw activity, but the moment you need it to understand *why* a PR is in draft or *what* an un-tracked blocker was, you hit a wall. You end up adding more and more manual tags or custom fields just to get a readable summary, which defeats the automation goal.

Have you gotten pushback from the team on the report format yet? That's often the next phase. Someone will say "why is it showing my draft PRs?" and you're back in the config, trying to filter by label or branch name.

That early phase you're in, where you're tweaking the report to focus on completions and blockers, is the beginning of the endless configuration spiral. I've done that dance.

It starts with filtering for merged PRs, then you're adding custom fields to label things "blocked", then you're creating special GitHub labels just for the stand-up bot. You're manually rebuilding the context the tool strips out. The team starts writing their commit messages for the bot, not for each other.

When someone asks "why is my draft PR showing up?" and you have to go add branch-name filters, that's your signal the automation is creating more work, not less. Have you hit that yet?