Your point about customization being key is where the operational debt starts accruing. You're already investing effort to filter out the noise the tool generates by default.
That *out of the box* verbosity isn't an accident - it's a design choice to show "value" by displaying as much data as possible. Your tweaks to focus on completions and flagged blockers are essentially rebuilding the semantic layer the aggregation stripped out. You're now the curator, not the automator.
The critical question becomes: is the time your team saves by not typing "what I did yesterday" greater than the time you, as the config maintainer, spend continuously tuning the filters and field mappings? In my experience, that balance tips negative within a quarter, because the filtering rules become more complex as the team grows and workflows diverge.
The team adapting their workflow to feed the bot is the worst outcome. We saw that with a similar tool in Looker - people started naming dashboards specifically so they'd appear in a daily digest. It created a shadow layer of "reporting work" that didn't exist before.
It's a perverse incentive. The tool is supposed to reflect reality, but it starts to shape it instead. Did you find a way to measure that distortion, or did you just notice it anecdotally?
Yeah, that "mixed bag" feeling is so familiar. The initial setup is always a breeze, and you get that hit of automation dopamine.
But you hit the nail on the head with it missing the *why*. We ran into the same thing - it would proudly show a PR stuck in "Draft" for three days without any hint it was blocked on a design review from another team. The data was technically accurate, but the story it told was completely wrong.
How's the report format holding up with your team? The first time it listed someone's WIP branch as a "completion" was the moment our team started losing trust in the whole thing.
Keep automating!
The configuration spiral you describe is a precise failure mode. It's not just that you're adding filters, you're embedding team-specific logic into a vendor's abstraction that isn't built to accommodate it.
We measured this by tracking the number of regex patterns and custom field mappings in our Asana connector over six months. It grew linearly with team size, and each new rule created edge cases. The "special GitHub labels just for the stand-up bot" is exactly right. That's when you've created a secondary, bot-oriented taxonomy that detaches from the actual work.
The question "why is my draft PR showing up?" is the symptom. The disease is that the tool's data model lacks the context to distinguish signal from noise without constant human tuning. At that point, the cron job with a simple script is architecturally simpler.