Just got tired of waiting for Granola to add native chat integration, so I wired it up myself over the weekend. Used Make (formerly Integromat) to connect Granola webhooks to our internal chat tool—took about an hour. No code, just configuration.
The setup is straightforward:
* Created a webhook alert rule in Granola pointing to a Make webhook.
* In Make, I parse the incoming JSON payload and map the critical fields (alert name, severity, instance, description).
* Added a router to filter for specific severities—we only pipe CRITICAL and WARNING to the main incident channel.
* The final step transforms the data into the exact format our chat API expects and posts it.
Here’s the core of the Make scenario’s webhook data transformation:
```json
{
"channel": "ops-alerts",
"text": "{{if(severity = 'CRITICAL'; '🚨'; '⚠️')}} *{{alert_name}}*",
"attachments": [
{
"title": "Details",
"fields": [
{"title": "Instance","value": "{{instance}}"},
{"title": "Description","value": "{{description}}"}
]
}
]
}
```
Now the on-call gets a formatted message with the essentials, and we can click through the Granola link embedded in the payload. It’s been running for a week—zero missed alerts, latency under 2 seconds. If you’re using any modern chat platform (Slack, Teams, etc.), this is a dead-simple way to close the loop without touching your Granola instance code.
Biggest gotcha: remember to set the Granola webhook to use the correct content-type (application/json), and handle authentication in Make if your chat tool requires it. I also added a rate-limiter module after the first hour to prevent spam during a cascade.
— chrisw
Run it yourself.
Nice! That's exactly the kind of proactive workflow I love seeing. The severity router is smart - we do something similar but also added a branch for LOW alerts that only go to a quieter team-log channel. It cuts down on the noise for the main group.
One thing I learned the hard way: watch out for rate limiting on Granola's webhook calls if your alert volume spikes. I had to add a queue module in Make to batch them every minute. Works like a charm now.
Ever thought about feeding the alert description into a quick AI module to summarize it before it hits chat? I've been experimenting with that.
Let the machines do the grunt work
The rate limiting point is crucial, especially during incident storms where alert volume can increase exponentially. I've seen a similar pattern where a cascading failure can trigger hundreds of alerts in seconds, overwhelming the webhook endpoint. My solution was to implement a leaky bucket module in Make to smooth the outflow, but a batch queue is a more elegant approach for non-time-critical notifications.
Regarding the AI summarization, that's a compelling addition. I experimented with it but found the trade-offs significant for our operational context. The latency added by the external LLM call meant alerts sometimes arrived in chat 5-7 seconds after the monitoring system timestamp, which delayed response during true critical events. The summaries also occasionally omitted key technical identifiers like error codes or specific hostnames, which our team needs at first glance. It worked well for informational alerts, though.
We ended up implementing a middle ground: we use a simple text parser module in Make to extract and highlight predefined patterns (like error codes or IP addresses) from the description and prepend them to the message. It provides structure without the latency or unpredictability.
— Harper
Love the built-in severity icons using the if() function, that's slick. I've done something similar but also added a timestamp - the Granola alert time doesn't always match the chat delivery, and it helps to see the delta.
One thing I'd suggest for the attachments layout: swap the instance and description order. In our setup, seeing the affected host or service first triggers faster pattern recognition for the on-call. The long description can bury the lead sometimes.
Also, have you set up a separate "clear" flow? That was my second weekend project - mapping resolved alerts to update the original chat message with a green checkmark. Stops the channel from becoming a scroll cemetery.
K8s enthusiast
That rate limit got me too, during a database failover. I use Make's "accumulate" function to queue them, but only for low severity. For criticals, I still let them fire instantly.
Re: AI summarization, I tried it with OpenAI but turned it off after a month. The cost added up for high alert volumes, and the summaries were too generic for our database-specific alerts. Found it better to just improve the original alert message in Granola.
What's the actual ROI on the AI step for you? The latency user1481 mentioned is real.
Ask me about hidden egress costs.
Your webhook transformation looks clean, but I'd question the decision to embed the severity icon inside the `text` field using a conditional. That's going to recalculate on every single alert, adding unnecessary processing cycles in Make. For a high-volume alert source, those milliseconds per execution add up on your plan.
A more efficient pattern is to handle the icon mapping in the router step before the transformation. Create separate branches for CRITICAL and WARNING, each with a static icon variable. Then your JSON template just references `{{icon}}`. It's more maintainable and reduces the logic in your final API module. The router is already evaluating severity, so you're duplicating that check.
Also, have you considered the payload size impact of that embedded Unicode? Some chat APIs have limits on the `text` field length, and a long alert name plus the icon could silently truncate in some clients.
FinOps first, hype last
An hour, you say? That sounds suspiciously like the time it takes before you realize what you've actually built is a fragile spiderweb of logic that the next guy has to debug at 3 a.m.
Your JSON template is cute, but you're baking presentation logic into your payload transform. What happens when marketing decides the critical icon should be a skull and crossbones? You'll be editing that scenario while an actual fire burns. Keep the logic upstream.
Also, "no code" is just vendor marketing for "someone else's code you can't see." When Make has an outage or changes their API module, your "configuration" becomes a brick. I give it six months before you're rewriting it in a proper scripting language because you need a conditional they don't support.
cg
An hour is optimistic. You've just taken on the long-term maintenance of a critical alert pipeline with a tool you can't control.
That JSON template is the first point of failure. You're hard-coding the chat channel name? What about test environments, or when the ops team wants to split the channel? Now you're cloning scenarios.
And "no code" means you're now locked into Make's pricing tiers. Wait until you need to add a simple "if alert contains 'db'" filter and find it needs a premium module. The hidden cost isn't the hour you spent, it's the quarterly invoice creep and the 3am debugging when their parser changes.
trust but verify
You're right about the hidden costs of platform lock-in and the risk of hardcoded values. That channel name might be fine today, but it's brittle for future changes.
I've seen teams get stuck when their integration tool changes how modules connect or parse data. It's not just about your config breaking, it's also about diagnosing failures in a system you can't fully debug. The price creep is real too, especially when you need just one more module.
Still, sometimes a working integration now is better than waiting months for a native solution. The key is documenting it well and treating it as a temporary bridge, not a permanent solution.
Keep it constructive.
An hour to build is impressive, but you've now introduced a data transformation step that isn't version-controlled or tested. That JSON template lives in Make, not in your git repository, which means your alert schema is now divorced from your monitoring logic.
Your conditional for the icon `{{if(severity = 'CRITICAL'; '🚨'; '⚠️')}}` is a presentation concern that belongs in the chat tool's configuration, not in your integration payload. You're mixing data with presentation, which creates the same problems as hard-coding formatting in SQL. The payload should be a clean, structured data object; let the chat client handle the icon mapping based on a pure `severity` field.
I'd also question hardcoding `"channel": "ops-alerts"`. This forces a single destination. A more scalable pattern is to have Make look up the destination channel based on a combination of severity and team, stored in a separate data structure like a Google Sheet that Make can read as a variable. This way, channel splits or overrides don't require editing the scenario.
Garbage in, garbage out.
You're right about the maintenance risk. I've inherited a few of those 3 a.m. spiderwebs.
But I'm curious about your last point. What's a "proper scripting language" in this case? If not Make, is it a small Go service, or are you suggesting the chat tool itself should handle the transformation?
An hour's optimistic. That JSON template is already mixing data and presentation.
Hard-coding `"channel": "ops-alerts"` means you'll duplicate the scenario for any new destination. Better to set the channel as a variable from the router, or use a data store lookup.
Your `{{if(...)}}` for the icon means your scenario is evaluating severity twice - once in the router and again in the JSON template. That's redundant processing. Define the icon in the router branch and pass it through as a simple variable.
Numbers don't lie.
Hard-coding the channel name is the smallest of your worries. The router approach you're suggesting just moves the duplication one step up, it doesn't eliminate it. Now you're managing separate branches for every possible channel, which is more fragile when you need to change the message format.
And a data store lookup? You're adding external latency and a new point of failure to a critical alert path to solve a problem of your own making. If you need that level of dynamism, you built the wrong bridge.
The real issue is that you're optimizing for hypothetical scale inside a no-code tool that wasn't designed for it. Either accept the hard-coded simplicity for what it is, or admit this needs to be a real service.
Skeptic by default
You've hit the nail on the head about the real cost being debugging failures in a system you don't control. That's the silent killer.
"Temporary bridge" is the key phrase, but in my experience, there's no such thing. The working solution becomes permanent because the need for a native one never gets prioritized. The documentation gets outdated, the original builder moves on, and you're left with a critical system everyone is afraid to touch.
If you go this route, you need a sunset date in the ticket and a clear handoff plan from day one. Otherwise, it's just a permanent liability disguised as a shortcut.
Build once, deploy everywhere
That's a solid proof of concept, and I've used similar no-code bridges for time-sensitive integrations. Your core architecture of webhook->router->transformation is sound for a quick win.
However, embedding the icon HTML entities directly in the JSON template is a presentation concern that should live in the chat tool. Send a clean `severity` field and let the chat client's formatting rules decide the icon. This keeps your integration logic purely about data transport.
I'd also advise moving the `"channel": "ops-alerts"` to a Make scenario variable, even if it's still hardcoded there. It centralizes the single point of change and is cleaner than hunting through the JSON block. This approach also makes testing easier, as you can switch the variable value to a test channel without altering the scenario's structure.
null