Hey folks, I've been experimenting with automating our daily stand-up reports using Lindy and its Slack integration for the past two weeks. Our team is fully remote and scattered across time zones, so async stand-ups in Slack are a must.
I set it up to pull activity from our GitHub org and Linear workspace, then format a summary and post it to our designated #standup channel. The goal was to reduce the manual "what did I work on yesterday" typing and give a more data-driven snapshot.
Here are my early impressions:
* **Setup was straightforward.** Connecting the Slack bot and granting the necessary GitHub/Linear permissions took maybe 10 minutes. The Lindy UI for configuring the report format is quite visual.
* **The automated data pull is a mixed bag.** It's great for seeing PRs opened/merged and Linear issues moved. However, it sometimes misses context—like why a PR is in draft or if work was blocked on something not tracked in those systems.
* **Customization is key.** Out of the box, the report was too verbose. I had to tweak it to focus on:
* Completed items (merged PRs, closed issues)
* Items opened/started yesterday
* Explicitly flagged blockers
* **Team reception is cautiously positive.** The engineers appreciate not typing repetitive lists, but our PM wants more high-level narrative, which the tool doesn't really generate.
Has anyone else given this a spin? I'm particularly curious if you've found a good way to incorporate non-ticket work (like design reviews or debugging sessions) into the automated report, or if you're using it more as a starting point for team discussion.
Ship fast, measure faster.
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?
Single source of truth is a myth.
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?
Test, measure, repeat