Grafana's alerting is good at evaluation. What it does not do is wake anybody up in a structured way, track who is handling what, or escalate when nobody responds. Connecting the two is usually a thirty minute task that people make harder than it needs to be.
The shape of the integration
Grafana sends alerts to a contact point; a webhook contact point posts JSON to a URL. The friction is that Grafana's native payload is designed for Grafana, and most ingestion endpoints expect their own shape.
Option one: shape the payload in Grafana
Grafana supports customising the body a webhook contact point sends. Emit exactly the fields your target expects — a title, a severity and a description. Build the title from the alert name and the labels that identify the instance, so it is self-describing at 3am. Map severity deliberately, and note that many endpoints require specific casing and silently fall back to a default on anything unexpected.
Option two: a small relay
If customising in Grafana is awkward, put a small service in between that receives Grafana's payload, transforms it, and posts to the ingestion endpoint. Keep it fast and stateless, and monitor it — a relay that dies silently takes your entire alerting path with it.
Grouping and repeat intervals matter more than you think
Grafana re-sends firing alerts on a repeat interval. If your target creates a new incident for every request, a one hour repeat means one incident per hour. Before you finish, find out how your target deduplicates. If it deduplicates by source, the repeat interval is harmless. If it does not, set the repeat interval long or disable it and rely on the incident system for escalation. Getting this wrong is the most common cause of a Grafana integration being switched off a week after it was built.
Resolved notifications
Enable them so your incident system can close things out automatically. A resolved notification is just another webhook call, so your translation must distinguish firing from resolved.
One trigger per service, not one for everything
Creating one per service gives you three things: the incident source tells you which system fired, you can route different services to different rotations, and you can disable one noisy source without turning off everything.
Testing it properly
Do not test with "send test notification." Create a throwaway alert rule that fires on a condition you can trigger, let it fire naturally, confirm the incident appears with the right title and severity, then resolve and confirm it closes.