Stopping PostHog Survey Slack Notifications From Drowning Your Channel
No, not directly. PostHog's Slack destination for surveys posts one message per response, in real time, and there is no setting anywhere in survey notifications that batches those into a daily or weekly digest. A team asked PostHog for exactly this in an open GitHub feature request: "Our internal team wants to stay updated on survey responses but doesn't want to manually check individual surveys or deal with constant Slack pings throughout the day." As of this writing the request is still open, filed under feature/surveys, with no shipped digest option.
There's a workaround that gets closer than most teams realize, using a different PostHog feature than the one that's causing the noise. It won't hand you the response text in digest form, but it will replace the per-response pings with one scheduled Slack message. Below is how to set it up, what it actually covers, and the point where a count on a schedule stops being enough.
Why every response pings the channel by default
Survey notifications and insight subscriptions are two separate PostHog features that happen to both post to Slack, and mixing them up is the reason this feels unfixable. Setting up a Slack notification on a survey means opening the survey, going to its Notifications tab, adding a Slack destination, and picking a channel. That notification fires per response as soon as someone submits, and it's scoped to full completions by default. There's a toggle for whether partial responses count, but nothing that groups multiple responses into one message. If your survey gets forty responses in an afternoon, that channel gets forty messages.
This is by design for a single high-signal survey with a handful of responses a week. It stops being by design the moment volume goes up, or the moment you have four or five active surveys each posting to the same channel independently.
The workaround: subscribe to an insight instead of the survey
PostHog logs four distinct survey events: survey shown, survey sent (fires when someone answers a question), survey dismissed (fires when someone explicitly closes it), and survey abandoned (fires when someone navigates away before finishing, tracked once partial responses are turned on), each carrying the survey ID as a property. That means you can build a normal product analytics insight off survey sent, filtered to the survey (or surveys) you care about, instead of relying on the survey's own real-time notification.
Once that insight exists, subscribe it to Slack on a schedule: daily, weekly, monthly, or a custom interval like every two weeks, at whatever time of day you want it delivered. A dashboard subscription can bundle up to six insights into one message, so a response-count trend for three separate surveys can land as a single weekly post instead of three separate channels of live pings. PostHog can optionally attach an AI summary of what moved since the last delivery, though that consumes org AI credits and needs consent turned on first.
Turn off (or never create) the per-response survey notification, and turn on the subscription instead, and the volume problem is solved at the source: the channel gets one message a week instead of one message per respondent.
What the digest doesn't give you
The subscription is a real fix for volume, and it's also a narrower tool than it sounds. It delivers whatever the underlying insight computes, which for a trend on survey sent is a number and maybe a chart, not the response text. If your survey has an open-text "why" field, that answer isn't in the Slack message. Someone still has to open PostHog's results page to read what people actually wrote, which is the same manual step described in how to analyze open-text PostHog survey responses at scale. The digest tells you eleven people answered this week. It doesn't tell you what six of them said about checkout, or whether that overlaps with a support ticket from the same account.
It's also a count on a fixed schedule, not a threshold alert. A weekly digest that quietly reports "34 responses" the week something actually broke reads the same as a normal week until someone opens the chart and looks.
Ferngate's #customer-signal channel, before and after
#customer-signal was carrying two surveys: a rolling in-app NPS survey and a post-cancellation exit survey, both wired to PostHog's per-response Slack destination.
Rosalind, in the team's retro doc: We're at 60-something pings a day in customer-signal between the two surveys. I muted it on my phone two weeks ago and I don't think I'm the only one.
Teammate: Same. I still check it maybe twice a day but I'm scrolling past most of it.
Rosalind Achebe, who runs support ops at Ferngate, filed the PostHog feature request for a digest option, found the existing open issue instead, and moved to the subscription workaround: a dashboard with a survey sent trend for each survey, subscribed to #customer-signal every morning at 9. The per-response notifications came off both surveys the same day, and the sixty-odd pings became one message. Three weeks later the exit survey saw a real spike, a cluster of cancellations mentioning the same billing change, and nobody caught it until the weekly product review. A bar taller than usual on a chart nobody was watching closely didn't read as urgent the way a wall of same-afternoon Slack messages would have.
Three gaps the schedule doesn't close
The insight-subscription swap solves exactly one problem: it stops every response from generating its own Slack message. It leaves three things unresolved:
- The response content still requires a separate trip. A count subscription tells you volume moved. Reading what people said, especially open-text fields, still means opening PostHog directly, every time.
- A scheduled digest doesn't notice mid-cycle. Daily or weekly delivery means a real spike sits unflagged until the next scheduled post, unless someone happens to be watching the live chart.
- Nothing here connects a response to the account behind it. A subscription shows a response count. It doesn't say which of those responses came from an enterprise account renewing next month versus a free-tier trial that churned anyway.
That third point is where teams stop trying to make the digest do more and start looking for something that reads the responses instead of counting them.
#shared-customer-channel
Ranked topicsThat's the layer Modem works on, and it doesn't require picking a digest schedule at all. Modem's PostHog integration covers product analytics, feature flags, experiments, and error tracking; it doesn't ingest survey text directly. What it does read is Slack, so pointing PostHog's existing per-response survey notification at a channel Modem already monitors puts every response in front of the same triage layer as your support tickets and sales call notes. Modem doesn't reduce the number of messages PostHog posts. It reads all of them, clusters the ones that are actually the same complaint, counts how many accounts are behind each cluster, and surfaces the theme instead of the raw feed, so nobody has to scroll a wall of pings to notice that eleven of today's responses are the same billing complaint. That's a different fix than fewer messages: the channel still gets every ping, but a person only has to read the cluster summary instead of the sixty raw ones underneath it. Full disclosure: Modem is what we build, and this is the paragraph where that matters most for how you read it. Pricing is unlimited users on every plan, with usage-based volume beyond what's included, not a per-response charge for reading survey pings.
This doesn't replace PostHog for anything analytics does well, and it isn't the only way to cut Slack noise; how to stop Sentry Slack alerts from becoming noise covers the same problem for a different source using native routing rules, which PostHog's survey notifications don't currently offer at all.
Set this up for one survey today
Build one insight off survey sent for your noisiest survey, filtered to that survey ID, and subscribe it to the channel on a daily schedule. Turn the per-response notification off for that survey only, and watch for a week. If the digest feels thin the first time a real spike happens mid-cycle, that's the signal this workaround has a ceiling, not a sign you configured it wrong.
