Wazuh Slack and PagerDuty integration: what routing high-severity alerts involves
High-severity Wazuh alerts can be forwarded to Slack and PagerDuty through the integration method the Wazuh documentation describes, and the filters that decide what gets sent must be chosen before any notification goes out. The work covers webhook or API key setup on each destination, level and group filters that decide which alerts qualify, and the content of each message. Confirm the exact method against the current Wazuh integration documentation for the release you have installed, because the 4.14 release line receives patch releases every one to two months and configuration details can change between them.
Start with the destinations. Slack and PagerDuty each need a credential that lets Wazuh post into a specific channel or service, and the people who can create those credentials usually sit outside the security team. Confirm with your Slack workspace administrator which app or webhook type your policy allows, and with your PagerDuty account owner which service and integration type should receive security events. Store the resulting secrets in the Wazuh server configuration with restricted file permissions, record who owns each credential, and set a rotation owner before go-live. Never place them in tickets or shared documents.
Filters decide whether the integration helps or floods the people receiving it. Level filters set the minimum severity that triggers a notification, and group filters limit notifications to rule groups that map to real response actions, such as authentication failures on administrative accounts or file integrity changes on production hosts. Keep paging separate from channel posting: only a short list of rules should wake an on-call engineer, while broader alerts belong in a Slack channel for review. Before enabling either path, replay recent alerts from the indexer against the proposed filters and count how many would have been sent. A filter that produces dozens of pages per shift will be ignored within days.
Message content determines whether an on-call engineer can act without opening the dashboard. Each notification should carry the agent name, the rule description and identifier, the severity level, the timestamp, and a link back to the matching alert in the Wazuh dashboard. Review the fields that come from log data, because some sources include usernames, IP addresses or customer identifiers that may need masking or exclusion under your privacy and retention rules. Agree on a short first-response instruction for each high-severity rule so that the person receiving the page knows who to call next.
Plan for failure before anyone relies on the path. A revoked webhook, an expired PagerDuty key, a network restriction on outbound traffic, or a PagerDuty service outage can silently stop notifications. Send a test alert to each destination, confirm it reaches the intended on-call schedule, and repeat the test after every configuration change or credential rotation. Document the escalation route for when the integration itself fails, and assign an owner who reviews delivery logs on a set schedule. Verification is complete only when a page is received and acknowledged by the right person in the agreed time window.
What you need in place before routing alerts
Routing Wazuh alerts to Slack and PagerDuty depends on access and infrastructure owned by several teams. Confirm each item below before configuration starts, because a missing permission or blocked network path usually shows up only after the integration is built.
Wazuh deployment and release line
Confirm which Wazuh components exist before any routing work: the indexer that stores alerts, the server that analyzes agent data, the dashboard, and the agents producing the alerts. Record the exact 4.14 patch level in use and check the release notes for changes that affect alerting or integrations before you configure anything. If the server runs as a cluster, confirm which node will make the outbound calls and that the configuration can be applied consistently across nodes.
Slack workspace and channel permissions
Adding an incoming integration usually requires a Slack role that can install apps or create webhooks, and some workspaces require administrator approval first. Identify the workspace owner, the destination channels and who may post to them. Ask whether each channel is public or private, because a private channel needs the app invited by a member. Agree channel names for critical and routine alerts up front so the webhook is scoped to only the channels intended.
PagerDuty account access and service setup
Someone with permission to create a service in PagerDuty must set up the service, choose an escalation policy and generate an events integration key for it. Confirm which teams own the on-call schedules that will receive pages and who may rotate the key later. Store the key in your approved secrets store rather than in a ticket or chat message. Confirm plan and role limits with your PagerDuty administrator before the build starts.
Outbound HTTPS to Slack and PagerDuty
The Wazuh server makes the outbound calls to Slack and PagerDuty, so firewall and proxy rules belong on that host's egress path. Take current endpoint hostnames from each vendor's documentation and allow HTTPS only to those destinations. Confirm whether the server reaches them through an HTTP proxy, and whether the integration reads proxy settings or needs them set separately. Test each path from the server itself.
Certificate trust for inspecting proxies
If an inspecting proxy re-signs TLS traffic, the Wazuh server must trust the proxy's certificate authority or calls to Slack and PagerDuty will fail validation. Add the authority to the trust store the server and integration use, and confirm the change survives package updates. Keep certificate verification enabled, since disabling it hides the failure and sends alert content over an unverified path. Ask your security team who owns the authority and when it renews.
Named owner for alert rules
Assign one named person who approves which rule levels, rule groups and agent sources may reach Slack or page on-call staff. This owner sets thresholds, signs off routing changes and reviews alert volume with the responders who receive it. Without this role, noisy rules tend to accumulate and paging thresholds drift from what the on-call team agreed. Record the owner, a named backup and the change process in the runbook before the first alert is routed.
How Wazuh alerts reach Slack and PagerDuty
Knowing the path tells you where each routing decision is made. Wazuh agents on endpoints send events to the Wazuh server. The server decodes each event with its decoders, matches it against rules, and assigns a rule level and rule groups. The resulting alert is written to the Wazuh indexer, which stores it for search and the dashboard. The integration component reads matching alerts and forwards them to each configured destination. Slack and PagerDuty are separate destinations, so each one needs its own filter and its own credential. Before you build anything, map which team owns each hop, because a filter set at the wrong point can change what the indexer stores or what your on-call engineers receive.
In the server configuration, the integration block determines which alerts a destination receives. The documented selectors work on rule level, rule group and rule ID. Level is the broadest control and usually sets a severity floor for paging. Group and rule ID let you send a narrow set of detections to a specific Slack channel, such as authentication failures on privileged accounts. Combine selectors deliberately and test each block against recent alerts, since a block that matches too broadly will page people for routine events. The destination secret, such as a Slack webhook URL or a PagerDuty integration key, is referenced from the block by name. Confirm in the documentation where that secret file must live, who can read it and how it is rotated.
The exact configuration keys, the accepted value formats for level and group filters, and any packaged scripts for Slack or PagerDuty must be taken from the Wazuh documentation for the release you run. Keys and bundled scripts can change between releases, and the 4.14 line has received several patch releases in 2026, so copy the sample from the documentation page that matches your version and read the release notes before any upgrade. Also confirm the payload format each destination expects and whether the packaged method sends one message per alert or supports any form of grouping. Those answers shape how many notifications your team receives during a burst of events.
Write a custom integration script only when the documented method cannot meet a stated requirement. Examples include enriching messages with asset owner data, suppressing repeated alerts from the same agent and rule, or selecting a PagerDuty routing key by agent group. Custom code becomes your responsibility. It must be tested after each Wazuh upgrade, must handle failed deliveries and retries, and must keep secrets out of logs and error output. Ask your integrator to record the requirement that justifies custom code in the written scope, so the decision and its maintenance cost stay visible to the owners who will run it.
Configuring the Wazuh PagerDuty integration and Slack webhook step by step
This sequence connects a dedicated Slack alert channel and a PagerDuty service to the Wazuh server, so that high-severity alerts reach people who act on them. Each step ends with a visible check, so you can confirm the path works before real alerts depend on it.
Create a dedicated Slack alert channel and webhook
A Slack workspace administrator creates a channel used only for Wazuh alerts, then adds an incoming webhook app that posts to it. Keep the channel separate from general chat so alerts are not buried. Copy the webhook URL into your password manager and treat it as a secret. Done when a test message posted to the webhook from an administrator workstation appears in the channel.
Create a PagerDuty service with an events integration key
In PagerDuty, a service owner creates a service for Wazuh alerts, attaches the escalation policy that matches your on-call schedule, and adds an integration using the Events API v2 option. Copy the generated integration key into the same secure store as the Slack URL. Done when a test event sent with that key opens an incident on the service, which you then resolve.
Store both secrets on the Wazuh server
On the Wazuh server, an administrator places the Slack webhook URL and the PagerDuty integration key in files that only the root account and the account running Wazuh can read. Do not paste them into shared configuration repositories, tickets or chat. Confirm the ownership and permission bits with a directory listing and review who else has shell access. Done when the listing shows owner-only read access and no other user can open the files.
Add one integration entry per destination
The administrator adds a separate integration block to the Wazuh server configuration for Slack and for PagerDuty. Each block sets a minimum alert level and a group filter, so the Slack channel receives a broader set of high-severity alerts than the on-call service, if your design calls for that. Start with a narrow filter and widen it later. Done when the configuration validation check your Wazuh version provides passes without reporting errors.
Restart the integration component and confirm it loaded
The administrator restarts the Wazuh manager so the integration component reads the new entries. Then they review the integration and manager logs for lines that name each integration and show it loaded without errors. A missing secret file, a malformed block or a permission problem usually shows up here first. Done when both integrations report a clean load and no error repeats after the restart.
Send a controlled test alert end to end
The team triggers a known, harmless test alert on an enrolled test agent, using a rule or a test event agreed in advance and written in the runbook. The alert should meet the minimum level and group filter you set. Watch for the message in the Slack channel and an incident in the PagerDuty service, then check that the alert fields and the agent name are correct. Done when both destinations show the test alert, and the team resolves the test incident and records the result.
Record the filters and the owner of each destination
The security operations lead writes down each integration's level and group filter, the channel and service it targets, the secret storage location and the person who can rotate the Slack webhook or PagerDuty key. Add the test alert used in the previous step so future changes can be retested the same way. Done when the record is stored with your other Wazuh configuration documentation and a second engineer can follow it.
How alert fields map to Slack messages and PagerDuty incidents
This table maps the core fields of a Wazuh alert to the Slack message body and the PagerDuty incident summary, severity and custom details. Use it to decide which fields identify a repeated condition for deduplication and which fields on-call staff can safely see in chat or on a phone. Confirm every field path against the alert JSON produced by your installed release before you build the integration, because paths and nesting can differ between versions.
| Wazuh alert field | Slack message body | PagerDuty incident | Deduplication and on-call exposure |
|---|---|---|---|
| rule.id | Shown in the header line so analysts can search for the rule | Custom detail for rule identification; part of the dedup key | Strong dedup component with agent name. Safe to show. |
| rule.description | Headline text of the message | Incident summary, kept short and specific | Weak dedup key alone, since several agents can trigger the same rule. Safe to show. |
| rule.level | Severity label and the threshold that decides which channel receives the alert | Severity field, mapped from level bands you define | Use for routing and filtering, not as a dedup key. Safe to show. |
| agent.name | Host name in the body for triage | Custom detail agent_name | Strong dedup component with rule ID. Confirm your policy on internal host names. |
| agent.groups | Used to choose the Slack channel or webhook | Used to select the PagerDuty service or routing key | Routing only, not a dedup key. Safe to show. |
| timestamp | Event time shown in the message | Event time in custom details | Leave out of the dedup key because it changes on every event. Safe to show. |
| location | Log source shown for triage context | Custom detail for the originating log source | Weak dedup key unless the source is stable. Check for paths that reveal sensitive detail. |
| data and full_log | Omit or truncate; keep out of the main message body | Include only after review of what the decoded fields contain | Not a dedup key. Not safe by default because values can include user names, addresses or payloads. |
Choosing level and group filters to avoid alert fatigue
Decide what pages a person by asking two questions: does the alert need someone to act within a defined response window, and is a named owner ready to act on it? Rule level is the first filter, because the level assigned to each Wazuh rule tells the integration how serious the rule's author considered the event. It is a weak filter on its own, though. Levels are set per rule, so a high-level rule that fires often will still wake someone at night. Use the level threshold as the outer boundary, then narrow the paging path with rule IDs or agent groups. For each paging rule, write down the owner who responds and the action expected, and remove any rule that cannot name both.
Agent groups let production and development hosts follow different routes. In Wazuh, agents belong to groups that carry centralized configuration, so group membership is a practical scoping key once you confirm that every production host sits in a production group before paging is enabled. Configure the integration so that production alerts above your paging threshold reach PagerDuty, while development alerts only post to a Slack channel or fall below a higher level. Check the level and group filter syntax against the integration documentation for the Wazuh 4.14 patch level you run, then test with a controlled event on one host from each group. Mislabeled hosts can send pages to the wrong team, so review group membership before go-live.
Suppress a noisy rule only after someone has reviewed sample alerts with the rule's owner and recorded why the alert is expected. Local rule overrides in your custom rules file are the usual mechanism for this, and each override should carry a comment with the reviewer, the date and the reason, so an auditor or a new engineer can follow the decision. Keep informational alerts in one Slack channel and paging alerts in a smaller channel, so everyone who watches the paging channel can assume each message needs action. Recheck suppressions after each Wazuh upgrade and after major changes to the monitored estate, because rule content and log sources change over time.
Measure volume during a trial before enabling paging. Run the integration in posting mode to the informational channel for a trial period your team sets, and record daily alert counts by rule ID, agent group and level. Ask the rule owners to classify a sample of alerts as actionable or expected, then adjust the level threshold, group filters and suppressions until the candidate paging set produces only actionable messages. There is no universal threshold. The right values depend on your organization's own alert baseline, which must be measured in your environment with your agents, log sources and workloads. Ask the integrator to confirm the trial length, the volume metrics they will report and the change process in the written scope.
Protecting webhook URLs, integration keys and alert content
A Slack webhook URL and a PagerDuty integration key each let anyone who holds them post into your channel or page your on-call engineers, so they deserve the same handling as other credentials. The cards below cover where these secrets live, how they rotate, how the Slack app and PagerDuty service are scoped, what leaves your network inside alert text, and how filter edits are reviewed.
Restrict ownership and permissions on the server
The integrator configuration on the Wazuh server holds the Slack webhook URL and the PagerDuty integration key in plain text. Confirm that the file is owned by the account that runs the Wazuh server process or by root, that group and other users have no read access, and that backups and snapshots of the server inherit the same restriction. Check file permissions again after every upgrade or package reinstall, since packaging steps can reset them.
Keep secrets out of shared repositories
Wazuh rule, decoder and integration configuration is often kept in version control so that filter changes can be reviewed. Store the webhook URL and integration key outside that repository, for example in a secrets manager or a file injected at deployment time, and place a pattern check in the commit pipeline that rejects hooks.slack.com URLs and PagerDuty keys. Treat any value that reached a repository, a ticket or a chat log as exposed until it is rotated.
Document the rotation procedure
Write down who can rotate the Slack webhook and the PagerDuty integration key, where each one is changed on the Slack and PagerDuty sides, which Wazuh configuration must be updated, and how the Wazuh server is restarted or reloaded to pick it up. Test the procedure in a non-production environment before the first real rotation. Record the date of each rotation so that the next review can confirm the keys are still within your rotation policy.
Revoke exposed keys immediately
If a webhook URL or integration key appears in a screenshot, a public issue, a departed employee's notes or a log shared outside the team, revoke or regenerate it at the source before investigating further. Old values should stop working on the Slack and PagerDuty side, not just be removed from Wazuh. Afterward, check the Slack channel and PagerDuty service history for messages or incidents you did not create, and record what was exposed and for how long.
Scope the Slack app and PagerDuty service
Use a dedicated Slack app or incoming webhook for Wazuh, limited to the channels that need high-severity alerts, instead of a personal or general-purpose integration. In PagerDuty, create a separate service for Wazuh with its own escalation policy, so that a key compromise does not expose other services and an integration can be disabled without affecting them. Confirm with each vendor which permissions the app or integration actually grants, since these settings change between product versions.
Review what leaves the network
Alert text sent to Slack or PagerDuty is processed by third-party services outside your infrastructure. Review sample messages from each high-severity rule for usernames, internal hostnames, IP addresses, file paths and command lines, and decide whether each field is acceptable outside the network. Where it is not, limit the fields in the integration message or move the detail into a link to the Wazuh dashboard that requires login. Confirm the data handling terms of each vendor with your legal or compliance team.
Require TLS to external endpoints
Confirm that every outbound call from the Wazuh server to Slack and PagerDuty uses HTTPS and that certificate validation is not disabled in the integration script or in any proxy in the path. If your network uses a forward proxy or TLS inspection, verify that the inspection certificate is trusted by the Wazuh server and that the proxy logs do not capture alert bodies in plain text. Test the connection after any change to outbound proxy or firewall rules.
Control changes to alert filters
Level thresholds, rule group filters and integration settings decide which alerts leave your network and which pages on-call staff, so a silent edit can expose data or hide an incident. Route each change through the same review as other security configuration, record who approved it and why, and test the effect on a sample of recent alerts before deployment. Keep the previous version so that a faulty filter can be rolled back quickly during an incident.
Testing routing before on-call staff depend on it
Before any on-call engineer relies on a Wazuh route, run a written test plan end to end and have the Wazuh owner and the schedule owner both sign off on the results. The first test sends a synthetic alert at each configured alert level and confirms that it lands in the intended Slack channel or PagerDuty service with the expected severity. Use the same integration credentials, webhook or API key that production uses, but point them at a test channel and a non-paging PagerDuty service, or mark each test incident clearly. For every synthetic alert, record the rule ID, level and rule group that produced it, so any mismatch can be traced back through the rules and the integration configuration on the Wazuh server.
The second test checks the filters, because silence is only meaningful if it was verified. Generate events just below each threshold and events in rule groups that the team has agreed to exclude, then confirm that nothing reaches Slack or PagerDuty. Also check for duplicate delivery, which can happen when more than one integration block matches the same alert. Ask the security lead to confirm the threshold and group list in writing before testing starts, and store that list with the test results so later changes can be compared against it.
The third test covers the PagerDuty lifecycle: trigger, acknowledgment and resolution. Confirm whether the integration opens an incident for each alert or groups repeated alerts under one deduplication key, and whether that behavior matches what the on-call team expects. Confirm also what happens when someone acknowledges or resolves an incident in PagerDuty, and whether Wazuh or Slack is updated as a result. Check the behavior against the documentation for the integration version in use, and ask the PagerDuty administrator to confirm the service settings, since assumptions about these details tend to surface only during a real incident.
The fourth test simulates an unavailable endpoint. In a maintenance window, block outbound access from the Wazuh server to Slack or to PagerDuty and observe what happens: whether alerts are retried, dropped, or only written to the logs. Confirm that the alerts remain searchable in the Wazuh indexer and dashboard, so the fallback is a review path rather than a gap. Define a second notification route, such as email to a monitored mailbox, and test that route as well. Record the time the outage was detected and who was told, because those answers determine whether the fallback works in practice.
The final test is a walkthrough with the owner of the on-call schedule. Trace an alert from a high-severity rule to the person paged at each time of day, then follow the escalation path when nobody acknowledges within the agreed window. Confirm that the schedule, escalation policy and Wazuh routing agree on the same people. Keep the results in a versioned record, and repeat the full test after each Wazuh upgrade or rule change. Wazuh shipped six 4.14 patch releases between 17 March and 14 October 2026 (Wazuh release notes), so a quarterly retest is a reasonable starting point for a team that tracks upgrades closely.
Common failures in Slack and PagerDuty alert routing
This table lists six failures that most often stop Wazuh alerts from reaching Slack or PagerDuty, with the likely cause, the fix and the check that confirms the fix. Work through the first three rows first when alerts stop arriving, because they usually sit in the integration configuration itself. Confirm each check with a test alert before you widen level or group filters for production.
| Failure | Likely cause | Fix | Check that confirms the fix |
|---|---|---|---|
| No messages in Slack | Webhook was revoked, or the target channel was archived | Create a new incoming webhook for an active channel and update the integration URL | Send a test alert from the Wazuh server and confirm the message posts to the channel |
| No PagerDuty incident created | Integration key belongs to a different PagerDuty service than the one the on-call team watches | Copy the integration key from the intended service and update the integration block | Open the intended service in PagerDuty and confirm the test incident appears under it |
| Alerts missing from both channels | Level threshold is set above the level of the rule that should fire | Lower the level filter to match the rule, or confirm the rule level in the rule definition | Trigger a known test rule and compare its level with the configured threshold |
| Duplicate pages for one event | The same rule fires on many agents, and each alert creates its own page | Filter by rule group or agent group, and set the grouping key in PagerDuty before enabling pages | Run a controlled test and confirm that one event produces one incident for the chosen grouping key |
| Outbound connections blocked | Firewall or proxy blocks outbound HTTPS from the Wazuh server to Slack or PagerDuty | Allow the required outbound destinations, or set the proxy the integration supports | Test HTTPS from the Wazuh server host itself, not a workstation, and review proxy logs |
| Messages fail after a release change | A new Wazuh release changed alert fields that the integration message template reads | Compare alert JSON from the new version with the template, then update the field references | Run a test alert in a staging environment after upgrade and review integration logs for errors |
Questions buyers ask about Wazuh alerting to Slack and PagerDuty
How much does Wazuh alerting to Slack and PagerDuty cost to set up?
No fixed price applies, because the quote follows from the written scope. The self-hosted Wazuh software is open source with no license fee, so the cost is the labor to design, build and test the routing, plus any Slack and PagerDuty plan costs you already carry. The main drivers are the number of destinations (channels, PagerDuty services and escalation policies), how complex the level and group filters are, how mature your existing Wazuh rules and decoders are, and how many approval steps a rule change must pass. Ask the provider to itemize the quote by destination, rule set, test cycles, documentation and handover. Ask separately whether ongoing support is a retainer, since that recurs and the one-time build does not.
How long does a typical Wazuh to Slack and PagerDuty routing setup take?
The duration depends on your environment more than on the tools themselves. Timing moves with the number of destinations, whether Slack channels and PagerDuty schedules already exist, how quickly your named approver reviews rules, and how often your change windows open for testing. A setup with one channel and one schedule usually moves faster than one that splits alerts across several teams and severities. No standard duration is given here, so ask the provider to state the timeline in the written scope, with the dependencies that could delay it, such as access grants and the test window.
What access and people do we need to provide for this engagement?
You need to provide four things before work starts. First, Slack admin access or the rights to install and configure an app and incoming webhook in the target workspace. Second, PagerDuty admin access to create or update services, integration keys and escalation policies. Third, an owner for the on-call schedule who can confirm who is paged, at what hours and in what order. Fourth, a named approver who signs off each routing rule and filter before it goes live. A test window is also needed so that noisy alerts can be observed without paging real responders. Confirm which of these your identity and approval processes allow before the engagement is scheduled.
Can our internal team set up Wazuh alerting without outside help?
Yes, many teams can, provided they have the right skills and time. The work requires familiarity with Wazuh alert levels, rule groups and the integration mechanism described in the Wazuh documentation for the release you run. It also requires Linux administration on the Wazuh server, administration rights in Slack and PagerDuty, and careful handling of webhook URLs and API keys. Teams often underestimate the tuning stage, where rules are reviewed against real alert volume with the people who respond. An outside partner can help when the first deployment is tight on time, or when the internal team needs a documented, repeatable build that another engineer can run.
Which Wazuh alert levels and rule groups should go to Slack or PagerDuty?
Send only alerts that a person must act on to a paging channel, and send the rest to a lower-urgency channel or the Wazuh dashboard. Start with the highest alert levels and a short list of rule groups tied to clear response actions, such as authentication failures on privileged accounts or changes to critical files. Test each filter against a sample of recent alerts and record the expected daily volume. Confirm the exact level values, the integration configuration and the filter syntax against the Wazuh documentation for the 4.14 release line you run, since Wazuh publishes patch releases every one to two months and configuration details can change between versions.
How do you stop Wazuh alerts from causing alert fatigue in Slack?
Alert fatigue usually comes from routing too many low-value events to a channel that people read on their phones. The practical controls are narrower filters, one channel per severity or responder group, and suppression for rules that repeatedly fire on known-benign activity after the owning team has reviewed them. Many teams also set aggregation or thresholds so that a burst of related events produces one notification. Review the count of messages per channel during the test window and again after go-live. Record each change with the approver's name so that a later reviewer can see why a rule was narrowed or suppressed.
What ongoing work follows after Wazuh alerts reach PagerDuty?
Several tasks recur after go-live. Slack webhook URLs and PagerDuty integration keys need rotation under your secret management policy, and each rotation must update the Wazuh configuration without dropping alerts. Wazuh upgrades recur as well, and the 4.14 line received six patch releases in 2026, so the integration should be retested after each upgrade. Threshold and filter reviews are needed as new rules are added and as your environment changes. On-call schedules also change, so the schedule owner must keep PagerDuty current. DeployOpen offers these tasks as a retainer, and the scope for that work is agreed in writing.
How DeployOpen scopes and delivers Wazuh alert routing
DeployOpen scopes Wazuh alert routing to Slack and PagerDuty as a fixed-scope piece of work, starting from the alerts your team needs to act on and the people who respond to them. We build the webhook and key setup in your own Wazuh environment, then test filters with sample alerts before anything pages an on-call engineer. Ongoing tuning is available as a retainer.
How we scope
- The written scope names which Wazuh alert levels, rule groups and agents feed Slack channels and PagerDuty services.
- We record who owns each Slack channel and PagerDuty escalation policy, and who approves changes to routing.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We configure the Wazuh integration and the Slack incoming webhook or app, with credentials kept out of plain-text configuration.
- PagerDuty keys are created per service, so each team's alerts reach its own on-call schedule.
- Level and group filters are tested against sample alerts from staging before any message reaches a production channel or pager.
How we hand over
- Test evidence records each sample alert, the rule that matched, and the channel or service that received it.
- Runbooks cover the filter logic, webhook and key rotation, and how to silence or reroute a noisy rule group.
- Your team receives configuration files, documentation and a walkthrough with the people who will maintain the routing.
How we support
- Retainers cover tuning of level and group filters as new Wazuh rules and agents are added to the environment.
- Wazuh upgrades can change alert fields and integration behavior, so routing is retested after each planned upgrade.
- Credential rotation and changes to on-call schedules are handled through the agreed change process, with a written record.
