Getting Graylog alerts to the people who act on them
A SOC or platform team that has built good Graylog searches still loses time when alerts stay inside the Graylog interface. The alert has to reach the channel where responders already work, and that depends on which notification types your Graylog edition includes. Alerts come from event definitions, which run a search on a schedule or in real time and raise an event when the condition matches. Notifications are attached to those events. The Graylog Open product page names PagerDuty, Slack and email as notification targets, so those three are the starting point for a team on Graylog Open. Microsoft Teams, HTTP and Custom HTTP notifications should be treated as edition-dependent until you confirm them against the current documentation and your license.
The edition boundary matters early because it changes the budget conversation. Graylog Open is free with no volume limits and community support, while Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security at 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units, according to the Graylog pricing page. Those license fees are recurring and sit alongside the infrastructure, MongoDB, Data Node or OpenSearch and staff time you already carry. Ask any partner or vendor to quote the notification set you need by name, and confirm which features are included in the license tier you plan to buy rather than assuming a feature list from a product page.
Before you build, decide who receives each alert class and whether a human must be paged at night. Confirm the PagerDuty, Slack and Teams integration details in your own tenant, including which channels or services receive which priorities, and test one notification end to end with a non-production event definition. Check that the notification is sent to the correct recipient set and that a second alert does not page the same person for the same incident. Plan for credential handling, since webhook URLs and integration keys are secrets that must be stored and rotated like any other, and for a fallback path if the chat or paging service is unavailable during an incident.
Which notification fits which responder workflow
This table compares the notification types named for alert delivery by where responders work, what each one needs configured, and which Graylog edition you must confirm before building it. The Graylog Open product page names PagerDuty, Slack and email, so confirm Microsoft Teams, HTTP and Custom HTTP against the current notification list for Graylog 7.2 before you commit to a design. Read each row as a checklist item for your own environment.
| Notification | Where responders work | What to configure | Edition to confirm |
|---|---|---|---|
| Slack | A shared channel where the on-call team already discusses incidents | Slack webhook or app credentials, target channel, and a message template that limits event fields | Confirm against Graylog 7.2 notification list and the Open product page |
| Microsoft Teams | A Teams channel used by operations or security staff | Incoming webhook for the channel and a message template reviewed for sensitive fields | Confirm whether this type is listed for your version and edition |
| PagerDuty | On-call schedules and escalation policies for paging a person | Integration key for a PagerDuty service and a severity mapping from Graylog priority | Named on the Open product page; confirm current behavior for your version |
| Inboxes, shared mailboxes or ticket intake addresses | SMTP settings, recipient list and a subject line that avoids exposing event details | Named on the Open product page; confirm SMTP prerequisites in your environment | |
| HTTP | A receiving endpoint such as a ticketing or SOAR tool | Target URL, authentication method, and a payload that carries only the fields the receiver needs | Confirm edition and availability for your Graylog version |
| Custom HTTP | Tools that need a specific request body, headers or templating | Request template, headers, credentials stored outside the template, and retry expectations | Confirm whether this needs Enterprise for your version |
| Script | A local host that runs an approved script | Script path, host security, timeouts and the data the script receives | Covered on the Enterprise script notification page; confirm before planning |
How to configure a notification and test it end to end
This sequence takes one Graylog alert from a confirmed edition and a destination channel to a delivered test notification with the expected event fields. Each step ends with a check so the team knows the path works before a real alert depends on it.
Confirm the Graylog edition and license
The Slack, Microsoft Teams and PagerDuty notification types depend on the Graylog edition and license in place, so confirm this before anyone builds anything. Ask the Graylog administrator to check the license under the system settings and compare the installed edition with the notification types listed on the Graylog pricing page and in the Graylog documentation for your version. The step is done when the administrator can name the edition and you have written down which notification types it includes. If a type is missing, confirm with Graylog whether your license covers it before changing the design.
Create the incoming webhook or integration key
In the destination tool, create the credential Graylog will use to post to it. For Slack and Microsoft Teams this is usually an incoming webhook scoped to one channel, and for PagerDuty it is an integration key on a specific service. Create the credential in a dedicated test channel or test service, not a production one, and record who owns it. Store the URL or key in your secrets manager rather than in a shared document. The step is done when you can send a manual test message to the test channel with a command-line request or the tool's own test feature, and the message appears.
Create the notification in Graylog
In Graylog, open the notifications section under the alerts settings and create a notification of the matching type, such as Slack, Microsoft Teams, PagerDuty or the Custom HTTP notification for other tools. Enter the webhook URL or integration key, a clear title that names the destination and environment, and any message template you need. Keep the message to the fields responders need, since the template decides what leaves Graylog. The step is done when the notification saves without an error and appears in the notification list with the name you chose.
Test the notification from Graylog
Use the test function on the saved notification, if your Graylog version offers it, before attaching it to any event definition. Watch the destination test channel or service for the message. If nothing arrives, check the Graylog server log for the notification's delivery error, confirm outbound network access from the Graylog server nodes to the destination, and verify the URL or key was copied in full. The step is done when the test message appears in the test channel with the title and body you configured.
Attach the notification to a test event definition
Create or edit an event definition that runs against a narrow test stream, such as a stream fed only by a sample input or a known test host. Set a condition that matches a message you can generate on demand, and add the new notification under the notifications section of that definition. Keep the event definition disabled for real streams until the test passes. The step is done when the event definition saves and shows the notification as attached.
Send a test event and check its fields
Generate a log message that matches the test condition, using a test input, a GELF message sent from a test host, or a replayed sample. Wait for the event definition to evaluate and confirm the event appears under the events view with the expected source, user, host and priority fields. Then check that the destination message shows those same fields in the expected places. A missing field usually means the message template or the event's field selection is wrong, not the destination. The step is done when a fresh test event produces one destination message with every field you planned to send.
Record the field list and approve for production
Write down the exact event fields the notification sends, the destination channel or service, the owner of the credential and the test results. Compare that list with your data handling rules, because every field in the message leaves Graylog for a third-party service. Remove any personal data or sensitive values that responders do not need in chat or paging. Then repeat the test on the production stream with a controlled event, or confirm with the responder team that they accept the message. The step is done when the record is signed off and the production event definition is enabled.
Limiting which event fields leave Graylog
Limiting the fields that leave Graylog matters because a notification is a copy of event data sent to a third party. The body of a Slack, Teams or PagerDuty message can carry user names, host names, IP addresses, and any message text that Graylog pulled into the event. Before you turn on a notification, decide which fields a responder needs to act on the alert and treat everything else as data that stays inside your Graylog deployment. Most responders need the event title, the priority, the affected host or user, the time window and a link back to the event or search. They rarely need the full raw log line.
When you write the notification message template, reference only the fields you have chosen, and keep the template short enough that it does not reproduce whole messages. Full raw messages often contain authentication details, query strings, request bodies or personal data that were never meant to reach a chat channel or a paging service. Check the exact event and message fields your Graylog version exposes in the template editor, and confirm with the vendor documentation whether any filtering or redaction option exists for the notification type you plan to use. Do not assume a field filter exists until you have tested it on a sample alert.
For each destination, record what it stores, how long it keeps messages, who can read the channel, the paging rota or the incident history, and whether the vendor's data handling terms fit your classification rules. A Slack channel with many members, a Teams channel with external guests or a PagerDuty incident visible to a broad on-call group each widens the audience for that data. Ask your Slack, Microsoft and PagerDuty administrators to confirm retention and access settings, and send a test alert containing only the fields you chose. Review the result again after any change to the event definition.
Security risks when alerts leave Graylog
Every Slack, Teams, PagerDuty, email or HTTP notification copies part of an event out of Graylog and into a system you may not operate. The cards below cover the places this copy creates risk: the credentials that authorize delivery, the access granted to those destinations, the retention outside your control and the content that gets duplicated or exposed.
Webhook URLs and integration keys
A Slack or Teams incoming webhook URL and a PagerDuty integration key both let anyone who holds them post into that channel or service. Store them in Graylog's notification configuration rather than in shared runbooks, restrict who can edit notifications, and rotate a key if it appears in a ticket, chat or screenshot. Ask your team which people can view the notification settings, since read access can expose the full URL.
Over-broad destination access
A channel that every engineer and contractor can read will receive alert details meant for a small response group. Before connecting Graylog, confirm who belongs to the Slack channel, Teams channel or PagerDuty escalation policy that will receive each alert, and whether guests or external members have access. Mapping each event definition to a specific destination keeps sensitive alerts away from broad audiences.
Retention outside your control
Once a notification is posted, Slack, Teams and PagerDuty keep their own copies under their own retention and export settings, and Graylog's retention policy does not reach them. Ask each team which workspace retention, eDiscovery or export rules apply to the channel or service, and where the destination is hosted. Decide which fields are acceptable to keep there, since a deleted Graylog index will not remove the message from the chat.
Event fields that leave Graylog
A notification template often includes the full message, source address and user identifiers from the triggering log. Those fields may contain session tokens, personal data or internal hostnames that the responder does not need in a chat window. Limit the notification body to the title, priority, affected host or user and a link back to the event, and review sample notifications before enabling them for a live stream.
Duplicate alert content
A single event that matches several definitions, or a condition that re-fires while an incident is open, can post the same detail to several channels and create several tickets. Duplicates multiply every exposure in this list. Set the event definition's grouping and backlog settings deliberately, and test how often a sustained condition repeats before connecting a paging service, so each incident produces one notification per destination.
Untested notification changes
A template or destination change can send raw event content to the wrong place without any visible error in Graylog. Keep a short test checklist for each notification: send a test event to a non-production channel, confirm the fields shown, confirm the recipient group and check that the credential still works after any rotation. Repeat the check after Graylog upgrades, since the notification configuration may change between releases.
Questions teams ask before setting up Graylog alert notifications
Can we send Graylog alerts to Slack, Teams or PagerDuty on the free edition?
Graylog Open can send alerts to PagerDuty, Slack and email, according to the Graylog Open product page, so a team on Open can start there. The Graylog Open product page also describes Open as source-available under the SSPL-1.0 license, which is not an OSI-approved open source license, so confirm the terms with your legal team before you build a production dependency on it. Microsoft Teams, HTTP and Custom HTTP notifications, and the Script notification are Enterprise features that you should confirm against the current feature list before you commit to a design.
What does Graylog Enterprise or Security cost for alert notifications?
The Graylog pricing page lists Graylog Enterprise from 15,000 US dollars per year and Graylog Security from 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units. Licensing is based on processed data, with no per-user or per-device fees, so the cost moves with your ingest volume rather than your headcount. Ask for the quote to state the processed volume it assumes, the edition, and whether it covers the notification channels you need.
How much effort does a Graylog alert notification setup take?
The effort depends on how many event definitions you are wiring up, how many channels each one needs, and how mature your on-call process is. Build effort grows with each Slack channel, Teams channel and PagerDuty service you map to a team, plus the test cases that confirm each notification arrives with the right fields. Expect the work to include defining who owns each alert, agreeing on severity, and testing failure paths such as an expired webhook or a PagerDuty key that changed. Ask any partner to list those items in the written scope.
Can our own team configure Graylog notifications without a partner?
Yes, if your team already runs Graylog and has an owner for the event definitions, the notification channels and the on-call routing. The work is mostly configuration, but it needs someone who understands your search queries, your on-call rota and the fields your responders need. Teams without a Graylog operator often underestimate the testing and the ongoing tuning. A partner is useful when you want a fixed scope, a second pair of eyes on field exposure, or a handover that your staff can maintain.
How long does setup take, and what changes the timeline?
The timeline is driven by the number of alerts, the number of destinations, whether Enterprise licensing is already in place, and how much agreement the on-call teams need before go-live. A small set of alerts to one Slack channel is a short job, while routing many alerts to several teams with PagerDuty escalation policies takes longer. Confirm the duration in your written scope and ask what happens if a channel or license is not ready on the planned date.
How do we stop alert noise and duplicate notifications?
Noise is controlled mostly in the event definitions, before a notification is sent. Aggregation conditions, lookback windows and grouping by user or host decide how many events are created, and notification settings decide whether repeated events reach a channel again. For PagerDuty, the event key should identify the incident so that repeats update one incident instead of opening new ones. For Slack and Teams, route only high-priority events to busy channels and send the rest to a triage stream. Test duplicates explicitly, because a retry after a timeout can produce a second message.
What event fields leave Graylog when an alert is sent?
Every notification carries the event data you choose to include, so the fields in the message template define what leaves your environment. A message that includes usernames, IP addresses or raw log lines sends that data to Slack, Teams or PagerDuty, which may be outside your data residency or retention rules. Limit the template to the fields responders need to act, such as the event title, priority and a link back to Graylog, and review the template with your security and compliance leads before go-live.
Keeping notifications reliable after go-live
Notifications stop working quietly, so the first ongoing task is a recurring review of which event definitions send to which channels. Keep a register that lists each event definition, its notification targets (Slack channel, Teams channel, PagerDuty service, email or HTTP endpoint), the owner of that alert, and the date the route was last tested. Review the register whenever a team reorganizes, a channel is renamed or archived, or a PagerDuty service changes escalation policy. Stale routes are the most common cause of alerts that fire in Graylog but never reach a responder, so check that every critical event definition still has a live destination and a named human owner.
Webhook URLs, integration keys and tokens need a rotation process with a named owner and a record of where each credential is configured. Slack incoming webhooks, Teams connectors and PagerDuty integration keys are all stored in Graylog notification settings, so a rotation means updating each notification that uses the old value and then sending a test event. Confirm with each vendor how that credential is revoked and whether the old value stops working immediately, and confirm how Graylog stores the secret in your configuration. Plan rotation as a change with a test step, not as a silent swap.
Destination outages and upgrades are the two events that need a scheduled check. When Slack, Teams or PagerDuty is unavailable, a notification can fail without a clear signal in the search results, so define a fallback route, such as a second channel or email, for critical alerts and review Graylog server logs for failed notification attempts. After each Graylog upgrade, send a test notification through every channel type in use and confirm the message content, formatting and the event fields it carries, because upgrades can change notification behavior. Repeat the same test after any change to the Graylog server's network path, proxy or certificate trust store.
How DeployOpen scopes and delivers Graylog notification work
DeployOpen treats Graylog alert notifications to Slack, Microsoft Teams and PagerDuty as a scoped piece of work on a self-hosted Graylog deployment inside your own infrastructure. We agree on which event definitions reach which channel, which event fields leave Graylog, and which edition each notification type requires before any configuration begins.
How we scope
- Written scope lists each event definition, the channel it notifies and the responder group receiving it.
- Scope records which notification types need Graylog Enterprise and which are available on Graylog Open.
- Field review defines which event fields may leave Graylog and which must stay inside your environment.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- Notification channels are configured in a test environment and checked against sample events before production.
- Message templates are written so responders see the user, host and source without extra event data.
- Credentials for Slack, Teams and PagerDuty are stored and rotated under your secrets handling standards.
- Each notification path is tested for delivery failures, duplicate messages and recovery after an outage.
How we hand over
- Handover documents each notification route, its owner, its edition requirement and its test procedure.
- Runbooks explain how to add a channel, pause a notification and rotate a webhook or integration key.
- Your team receives a walkthrough that covers how to confirm a notification fired and where it failed.
- Configuration is exported so changes can be reviewed in your own change process.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer for notification routes that change over time.
- Retainer work can cover re-testing notification paths after Graylog upgrades that change alert behavior.
- Changes to channels, responders or event fields follow the same written scope and review steps as the original build.
- Confirm with us which support hours and response terms apply before signing any retainer.
