Oxidized and Slack/Microsoft Teams: Real-Time Config Change Alerts with Hooks

Introduction

Network configuration changes rarely happen in isolation. An engineer updates a switch trunk, a firewall administrator modifies an access-control list, or a router receives a new routing policy. The change may be intentional, but its operational impact is not always immediately visible to the wider infrastructure team.

Without effective change notifications, network operations teams often discover configuration differences only after a connectivity issue, a monitoring alert, or an incident investigation. Even when configuration backups are automated, engineers may still need to log in to a configuration repository, identify the latest revision, and determine what changed.

Oxidized, Slack, and Microsoft Teams can work together to make network configuration changes visible to the people responsible for maintaining infrastructure. Oxidized collects and stores device configurations, while notification hooks connect configuration events to collaboration platforms. Engineers can then receive alerts when a configuration changes, when a device backup fails, or when a scheduled collection process finishes.

This approach is useful for internet service providers (ISPs), enterprise IT departments, managed service providers (MSPs), data centers, and organizations managing distributed network infrastructure.

The key is to design notifications around meaningful events rather than sending an indiscriminate message every time a device is polled.

This guide explains how Oxidized hooks work, how to integrate notifications with Slack and Microsoft Teams, how to publish configuration diffs safely, and how to troubleshoot and maintain a reliable notification pipeline.

It also covers implementation choices for environments where native integrations are insufficient, including custom scripts, incoming webhooks, structured messages, event filtering, and production security controls.

Quick Answer: How Do You Send Oxidized Configuration Change Alerts to Slack or Microsoft Teams?

Oxidized supports a hook system that executes actions in response to configuration collection events. Its documented hooks include post_store, node_fail, node_success, and nodes_done, although the exact available events and integrations should be verified against the installed version.

For Slack, Oxidized documents a slackdiff hook that can publish configuration differences when a changed configuration is stored. This integration requires the appropriate Ruby dependency, Slack credentials, and a compatible configuration output.

For Microsoft Teams, a practical approach is to use Oxidized’s exec hook to invoke a custom script. That script sends an HTTPS POST request to a Teams incoming webhook workflow. The workflow then publishes the notification to a designated chat or channel.

A typical implementation follows these steps:

1. Install and configure Oxidized to collect network device configurations.
2. Verify that configuration changes are stored correctly.
3. Create a dedicated Slack incoming webhook or Microsoft Teams webhook workflow.
4. Configure the appropriate Oxidized hook.
5. Send only the event information needed for the notification.
6. Test both successful configuration changes and failed collection attempts.
7. Secure webhook URLs, prevent sensitive configuration disclosure, and monitor notification delivery.

The result is an event-driven notification system that improves change visibility without requiring engineers to watch the configuration repository continuously.

Table of Contents

1. Understanding Oxidized and configuration change notifications
2. Key concepts and terminology
3. Architecture and event flow
4. Understanding Oxidized hooks
5. Preparing the environment
6. Integrating Oxidized with Slack
7. Integrating Oxidized with Microsoft Teams
8. Building a reusable notification script
9. Designing useful configuration change messages
10. Handling backup failures and operational alerts
11. Security and compliance considerations
12. Performance, reliability, and scalability
13. Real-world implementation scenarios
14. Troubleshooting common problems
15. Best practices and implementation checklist
16. Frequently asked questions
17. Expert recommendations and key takeaways

1. Understanding Oxidized and Configuration Change Notifications

What Is Oxidized?

Oxidized is an open-source network configuration backup and version-control application. It connects to supported network devices, retrieves their configurations, and stores configuration snapshots through a configured output backend.

It is commonly used to maintain historical records of configurations for routers, switches, firewalls, and other supported infrastructure devices.

Oxidized is especially useful when an organization needs to answer questions such as:

• What did the device configuration look like before the incident?
• Which configuration lines changed?
• When was the last successful configuration backup?
• Did an unexpected change occur on a production switch?
• Can an earlier configuration be retrieved for investigation or recovery?

Oxidized can work with network equipment from multiple vendors, subject to its supported models, device interfaces, and authentication requirements.

Its capabilities depend on the installed release, configured models, collection methods, and storage backend.

Why Configuration Change Alerts Matter

A configuration backup provides historical information, but a backup alone does not guarantee that an engineer will notice an important change promptly.

Consider an ISP managing hundreds of switches, routers, and firewalls. Oxidized may collect configurations automatically throughout the day, but engineers might not inspect the repository until a customer reports an outage.

An alerting integration makes the change visible in a collaboration channel where the operations team already works.

This can improve several operational processes.

Change accountability: Engineers can identify that a device configuration changed and investigate the corresponding revision.

Incident response: Unexpected changes can be investigated before they cause broader disruption.

Troubleshooting: Network engineers can correlate configuration changes with monitoring events, ticket updates, and service degradation.

Audit support: Notifications can help establish an operational record of detected changes, provided the organization retains appropriate logs and authoritative version history.

Team coordination: Network, security, and infrastructure teams can share a consistent view of relevant changes.

Notifications are not a replacement for a formal change-management system. They are an additional visibility mechanism that helps engineers act on information already captured by configuration management.

What Does Real-Time Mean in This Context?

In an Oxidized integration, real-time generally means that a notification is generated shortly after Oxidized detects and stores a configuration difference.

It does not necessarily mean that Oxidized detects every device change at the instant it happens.

The actual delay depends on:

• The Oxidized polling interval.
• The time required to connect to the device.
• Configuration retrieval and normalization.
• Comparison and storage operations.
• Hook execution time.
• Network connectivity to Slack or Microsoft Teams.
• Any queueing, retry, or workflow delays.

For example, if a device is polled every 30 minutes, a configuration change made immediately after a successful poll might not be detected until the next collection.

After detection, the notification can usually be sent without waiting for another scheduled polling cycle.

Therefore, the overall design is best described as near-real-time configuration change notification, with latency determined by the collection schedule and downstream delivery path.

2. Key Concepts and Terminology

Understanding the main components makes implementation easier and helps prevent common configuration mistakes.

Term	Meaning	Why it matters
Oxidized	Network configuration backup application	Collects and stores device configurations
Node	A managed network device in Oxidized	Identifies the source of a configuration event
Model	Device-specific logic used to retrieve and process configuration	Determines how supported equipment is handled
Output backend	Storage mechanism for retrieved configurations	Determines how configuration history is retained
Git	Version-control system frequently used with Oxidized	Preserves revisions and supports configuration diffs
Hook	An action triggered by a defined event	Connects configuration activity to notifications
post_store	Event triggered after a changed configuration is stored	Suitable for change notifications
node_fail	Event associated with a node collection failure	Supports backup-failure alerts
Incoming webhook	HTTPS endpoint that accepts messages from an external application	Connects Oxidized scripts to collaboration platforms
Configuration diff	Comparison showing differences between two configurations	Helps engineers understand what changed
Slack	Team collaboration platform	Provides notifications through channels and apps
Microsoft Teams	Workplace collaboration platform	Receives notifications through supported webhook workflows
Idempotency	Handling repeated events without unintended duplicate effects	Helps prevent duplicate tickets or repeated downstream actions

What Is an Oxidized Hook?

A hook is an action that Oxidized executes when a configured event occurs.

Depending on the hook type and installed version, the action may post a notification, invoke a command, publish an event to another system, or update an external repository.

Hooks allow administrators to extend the operational behavior of Oxidized without embedding every integration directly into its configuration collection logic.

For example, a post_store hook can notify a Slack channel after a changed configuration has been stored.

A separate node_fail hook can invoke a script when configuration collection fails after the configured retries.

The distinction between these events is important. A successful device poll does not necessarily mean that a configuration changed, and a failed poll does not necessarily indicate that the device configuration itself is incorrect.

What Is a Configuration Diff?

A configuration diff identifies differences between two configuration versions.

For example, a router configuration might change from:

interface GigabitEthernet0/1 description UPLINK shutdown

to:

interface GigabitEthernet0/1 description UPLINK no shutdown

The diff highlights the administrative state change.

This information is useful because an alert containing only a hostname provides limited troubleshooting value. A link to the relevant revision or a carefully controlled diff can help the engineer understand the change more quickly.

However, configuration diffs may contain sensitive information. Passwords, keys, community strings, access-control policies, internal addresses, and other operational details must be handled according to the organization’s security requirements.

A notification should therefore provide enough context to investigate the change without automatically distributing an entire configuration to every channel member.

3. Architecture and Event Flow

A reliable implementation separates configuration collection, event detection, notification delivery, and operational monitoring.

3.1 Architecture Components

The principal components are:

1. Network devices: Routers, switches, firewalls, and other supported devices.
2. Oxidized: Connects to devices and retrieves configurations.
3. Configuration storage: Stores snapshots and, where configured, version history.
4. Hook system: Reacts to events generated during the collection and storage process.
5. Notification script or native integration: Formats the event and sends it to the destination.
6. Slack or Microsoft Teams: Displays the notification to the relevant team.
7. Monitoring and logging: Records delivery failures and other integration problems.

A typical workflow proceeds as follows.

1. Oxidized starts a collection cycle.
2. It connects to a managed device and retrieves its configuration.
3. The retrieved configuration is processed according to the device model and output configuration.
4. Oxidized compares the new result with the previously stored configuration.
5. If a meaningful difference is detected and stored, the configured post_store hook runs.
6. The hook sends the event to the native integration or invokes a notification script.
7. The script formats the notification and transmits it to Slack or Microsoft Teams.
8. The collaboration platform publishes the message.
9. Engineers follow the supplied revision link or investigate the device through the appropriate operational tools.

The sequence is straightforward, but each stage introduces a potential failure point. A successful configuration backup does not guarantee successful notification delivery.

3.2 Native Integration Versus Custom Webhook

There are two principal implementation approaches.

Consideration	Native Slack hook	Custom webhook script
Initial setup	Relatively simple when supported	Requires script and endpoint configuration
Message formatting	Determined by hook capabilities and settings	Fully customizable within platform limits
Configuration diff support	Available through the documented slackdiff hook	Must be implemented explicitly if required
Microsoft Teams support	Not provided by the Slack-specific hook	Can be implemented through a Teams webhook workflow
Additional dependencies	Slack integration dependencies	HTTP client and script runtime
Error handling	Depends on hook implementation	Can be designed for explicit logging and retries
Maintenance	Track Oxidized and dependency compatibility	Maintain script, credentials, endpoint, and tests
Multi-platform delivery	Separate integrations may be required	One reusable notification service can support multiple destinations

The best choice depends on the operational environment.

A small deployment that needs basic Slack configuration diffs may benefit from the native hook. An enterprise environment requiring Microsoft Teams, structured alerts, routing rules, and centralized error handling may benefit from a custom notification script.

3.3 Recommended Production Design

For a production network, treat notifications as a separate integration layer.

The configuration collection process should remain focused on retrieving and storing device configurations. Notification logic should handle formatting, delivery, and errors independently wherever practical.

A recommended design includes:

• A dedicated notification account or service identity.
• A restricted notification channel.
• A securely stored webhook URL or API credential.
• A script with controlled execution permissions.
• Explicit timeouts.
• Logging that excludes secrets and unnecessary configuration content.
• A documented response to notification delivery failures.
• A link to authoritative configuration history when available.

For larger environments, a message queue or event-processing service can be introduced between Oxidized and the collaboration platform. This adds complexity but helps isolate collection operations from temporary downstream outages.

4. Understanding Oxidized Hooks

4.1 Important Hook Events

Oxidized documents several events that are useful for automation.

Event	Purpose	Typical use
node_success	Indicates successful configuration retrieval before storage	Collection health tracking
node_fail	Indicates a node collection failure after configured retries	Backup failure alerts
post_store	Indicates that a changed configuration has been stored	Configuration change notifications
nodes_done	Indicates completion of a node-processing cycle	Batch-level reporting

Confirm the behavior of these events in the documentation for your installed release before implementing production automation.

The most important distinction is between a collection event and a change event.

A device can be polled successfully without any configuration difference. Conversely, a device may fail to respond and therefore produce no new configuration snapshot.

For that reason, use post_store for change notifications and node_fail for collection failures rather than treating every successful poll as a configuration change.

4.2 How the exec Hook Works

The exec hook runs an external command when its configured event occurs.

The command can be a shell command, a script, or another executable that the Oxidized service account is authorized to run.

Oxidized documents event-related environment variables for the exec hook, including:

• OX_EVENT
• OX_NODE_NAME
• OX_NODE_FROM
• OX_NODE_MSG
• OX_NODE_GROUP
• OX_JOB_STATUS
• OX_JOB_TIME
• OX_REPO_COMMITREF
• OX_REPO_NAME

The exact values available depend on the event and the installed implementation. Test the variables in your environment before using them in operational automation.

Two additional settings deserve attention.

async determines whether the hook runs asynchronously. It can prevent a long-running external command from blocking the main execution path, but it does not guarantee reliable message delivery.

timeout sets the permitted execution time for the command. Choose a value appropriate for the operation, and avoid leaving network requests without a bounded timeout.

For example, the following configuration writes a basic event record to a log file when a changed configuration is stored.

hooks: change_audit_log: type: exec events: [post_store] cmd: '/usr/bin/printenv OX_NODE_NAME >> /tmp/oxidized-change-events.log'

This is a simple demonstration, not a recommended production audit design. It uses a temporary-directory path, does not include structured event metadata, and does not address log rotation or file permissions.

For production, use a dedicated script that validates inputs, writes structured logs to an approved location, and sends notifications through a controlled integration.

4.3 Why post_store Is Usually the Right Event

A configuration change alert should indicate that Oxidized has stored a changed configuration, not merely that a device was contacted.

The post_store event is therefore the natural starting point for change notifications.

A useful notification may include:

• Device hostname.
• Device group.
• Event type.
• Detection or storage timestamp, when reliably available.
• A link to the relevant configuration history.
• A brief summary of the change, if supported and safe.
• An instruction for the engineer to review the change.

Avoid claiming that the event proves who made the change. Oxidized identifies a configuration difference; it does not inherently establish the human identity of the person responsible.

Attribution requires correlation with other systems, such as network-device authentication logs, centralized AAA records, command accounting, change tickets, and administrative audit trails.

4.4 Understanding the Storage Backend

Hook behavior and diff availability can depend on the configured output backend.

For example, the documented slackdiff integration requires an output capable of generating a configuration diff. A simple file output may not provide the information needed by that hook, whereas a compatible Git-based output can maintain revision history.

Before implementing a diff notification:

1. Identify the active output backend.
2. Confirm that configuration revisions are retained.
3. Make a controlled configuration change.
4. Verify that the change appears in the stored history.
5. Confirm that the hook receives the expected event and metadata.
6. Test the resulting notification.

Do not assume that installing a notification dependency automatically makes every output backend compatible with every hook.

5. Preparing the Environment

Before configuring Slack or Microsoft Teams, verify that Oxidized itself is functioning correctly.

5.1 Verify the Installation

The following commands are useful on a typical Linux installation using systemd.

sudo systemctl status oxidized

This checks the service state. A running service is necessary but does not prove that devices are being backed up successfully.

Inspect recent service logs:

sudo journalctl -u oxidized -n 100 --no-pager

The output can reveal configuration errors, authentication failures, missing dependencies, model problems, and hook execution errors.

Check the installed executable and Ruby environment as appropriate for your installation:

command -v oxidized ruby --version

These commands are illustrative. Package-managed, containerized, and source-based installations can use different executable paths and runtime environments.

5.2 Verify Device Collection

Choose a test device and confirm that Oxidized can retrieve its configuration.

Check the following:

1. The device appears in the Oxidized node inventory.
2. The hostname and management address are correct.
3. The selected device model is appropriate.
4. SSH or another supported connection method works.
5. The service account has the necessary permissions.
6. The configuration is stored successfully.
7. A deliberate test change produces a new revision.

For example, changing a harmless interface description on a lab switch can help verify that a configuration difference is detected.

Do not test with a production routing change or firewall rule that could disrupt traffic.

5.3 Confirm the Service Account’s Permissions

The service account must be able to execute the notification script and read any required configuration files.

It should not receive unnecessary administrative privileges merely because it sends alerts.

A good permission model grants:

• Read access to the notification script.
• Execute access to the script.
• Read access to the minimum required configuration.
• Access to the designated secret source.
• Write access only to approved log or temporary directories.

Keep scripts owned by an administrative account or deployment process and avoid making them writable by every local user.

5.4 Establish a Test Destination

Create a dedicated test channel before enabling production notifications.

For example:

• Slack: #network-change-testing
• Microsoft Teams: a restricted channel used for infrastructure automation tests

This allows engineers to verify message formatting, permissions, and event behavior without flooding operational channels.

Record the expected result before testing. A successful integration should produce a notification for a stored configuration change, avoid sending a change alert for an unchanged configuration, and handle a failed notification without exposing secrets.

6. Integrating Oxidized with Slack

Slack integration can be implemented through Oxidized’s documented slackdiff hook or through a custom script that posts a message using a Slack incoming webhook.

These methods serve related but different purposes.

The native hook is useful when the goal is to publish configuration diffs using the capabilities already provided by Oxidized. An incoming webhook script is useful when the organization needs customized message formatting or wants to reuse the same notification logic across multiple destinations.

6.1 Choose the Slack Integration Method

Use the native slackdiff hook when:

• Configuration diffs are required.
• The output backend supports the necessary diff functionality.
• The installed Oxidized version supports the hook.
• The required Ruby dependency can be installed and maintained.
• Slack bot credentials and channel permissions can be managed securely.

Use a custom incoming webhook when:

• A concise event notification is sufficient.
• You want to control the message layout.
• The integration needs to be shared with other automation systems.
• You need a common script structure for Slack and Teams.

Do not assume that a bot token and an incoming webhook URL are interchangeable. They are different authentication and integration mechanisms.

6.2 Create a Slack Incoming Webhook

A Slack incoming webhook allows an application to send a JSON message to a configured Slack destination.

To create one:

1. Open the Slack API application management interface.
2. Create an application or select an existing application.
3. Enable incoming webhooks.
4. Add a webhook to the intended workspace and authorize the destination.
5. Copy the generated webhook URL.
6. Store it in an approved secret-management location.
7. Send a test message before connecting it to Oxidized.

The webhook URL should be treated as a secret. Anyone who obtains it may be able to post messages to its associated destination, subject to Slack’s current controls.

Never place the URL in a public repository, a published tutorial using real credentials, or a log that is accessible to unauthorized users.

6.3 Configure the Native slackdiff Hook

Oxidized documents a slackdiff hook that publishes configuration differences when the post_store event occurs.

The following is a representative configuration structure. Confirm the exact syntax and dependency requirements against the installed Oxidized release.

hooks: slack: type: slackdiff events: [post_store] token: <SLACK_BOT_TOKEN> channel: "<SLACK_CHANNEL_ID>"

Replace the placeholders with valid values. The token should not be published in configuration examples or committed to a repository without an appropriate secret-management mechanism.

The channel value should match the identifier format expected by the installed hook. Oxidized’s documented example uses a Slack channel ID, so do not assume that a display name such as #network-changes will work in every version.

The documented integration also requires the appropriate Ruby Slack client dependency. The dependency name can differ across versions or implementations, so follow the documentation that matches your installed release rather than installing a gem based on an unrelated tutorial.

6.4 Customize Slack Messages

The native slackdiff hook supports options for changing how notifications are presented. Depending on the installed implementation, these options may allow a formatted message, a link to a configuration revision, or the disabling of a configuration snippet.

A representative example is:

hooks: slack: type: slackdiff events: [post_store] token: <SLACK_BOT_TOKEN> channel: "<SLACK_CHANNEL_ID>" diff: false message: "%{node} %{group} %{model} updated"

This example disables the diff snippet and uses a concise message. Confirm the supported placeholders and exact behavior in the hook documentation for your version.

A short notification is often preferable for a busy operations channel. The alert should help an engineer identify the device and locate the relevant revision rather than reproduce a complete configuration.

For example, a useful message might contain:

Network configuration changed

• Device: core-sw-01
• Group: core-switches
• Event: Configuration stored
• Review: Open the relevant configuration history

Use a real revision URL only when your repository or interface actually exposes that resource. Do not invent commit links or imply that a private repository is publicly accessible.

6.5 Test the Slack Integration

After saving the configuration, perform a controlled test.

1. Validate the YAML structure.
2. Restart or reload Oxidized according to the installed service’s supported procedure.
3. Inspect the service logs for hook initialization errors.
4. Make a harmless change on a test device.
5. Wait for Oxidized to collect and store the changed configuration.
6. Confirm that the message appears in the intended Slack channel.
7. Verify that an unchanged poll does not create a false change notification.
8. Confirm that the notification does not expose sensitive configuration data.

If the native hook fails to load, investigate the dependency version, Ruby environment, token permissions, channel identifier, and output-backend compatibility before changing the entire integration design.

6.6 Native Hook or Slack Incoming Webhook?

The native hook is generally the better starting point when configuration diffs are central to the requirement. An incoming webhook is more flexible for simple event notifications and custom routing.

If both methods are enabled for the same event, a single configuration change could produce duplicate messages. Plan the notification path before enabling multiple hooks.

7. Integrating Oxidized with Microsoft Teams

Microsoft Teams can receive Oxidized notifications through an incoming webhook workflow. This is particularly useful in Microsoft 365 environments where infrastructure teams already use Teams for operational coordination.

The key distinction is that Oxidized’s documented Slack-specific diff hook is not a native Microsoft Teams integration. A Teams implementation therefore typically uses the generic exec hook and an external script.

7.1 Understand the Current Teams Webhook Approach

Microsoft documents incoming webhook workflows that accept HTTP requests and post messages to a selected Teams chat or channel.

These workflows are powered by Microsoft Power Automate and can process webhook payloads before publishing a message.

Microsoft has also announced the retirement of legacy Microsoft 365 Connectors in Teams. Because integration availability and setup requirements can change, new implementations should follow current Microsoft documentation and favor the supported Workflows-based approach where applicable.

Before starting, confirm that:

• The Workflows app is available in your tenant.
• Your account has permission to create or manage the workflow.
• The destination channel or chat is correct.
• The workflow’s authentication requirements are understood.
• At least one additional owner can maintain the workflow where supported.

A workflow linked to a single owner’s account can become an operational dependency if that account is disabled or the owner leaves the organization. Ownership and continuity should be part of the design.

7.2 Create a Teams Webhook Workflow

Use the following workflow to create a receiving endpoint.

1. Open Microsoft Teams and navigate to the intended team and channel, or choose the appropriate chat.
2. Open the Workflows experience.
3. Select a suitable template, such as a workflow for sending webhook alerts to a channel, or create a workflow using the supported webhook-request trigger.
4. Configure the destination and any authentication options.
5. Save the workflow.
6. Copy the generated webhook URL.
7. Store the URL securely.
8. Test the workflow independently before integrating Oxidized.

The exact interface and available templates can vary by tenant, permissions, and Microsoft product updates.

Treat the generated endpoint as a sensitive credential unless the chosen workflow explicitly requires and enforces another authentication mechanism.

7.3 Understand the Payload Format

A simple Teams webhook workflow may accept a JSON request containing a text field, while card-based workflows can use a structured card payload.

For example, a basic text request may use the following structure:

{ "text": "Oxidized detected a configuration change on core-sw-01." }

This is an illustrative payload for a workflow that accepts this format. It is not a universal payload for every Teams webhook configuration.

If the workflow expects an Adaptive Card, use the required card structure instead. Do not assume that a plain-text JSON object will work with every trigger.

The correct approach is to test the receiving workflow first with a minimal request. Once that succeeds, add event fields and formatting gradually.

7.4 Configure the Oxidized Hook

The exec hook can invoke a script that sends notifications to Teams.

For example:

hooks: teams_change_alert: type: exec events: [post_store] cmd: '/usr/local/bin/oxidized-teams-notify' async: true timeout: 30

This example assumes that the script exists, is executable by the Oxidized service account, and is installed at the specified path.

It also assumes that the hook implementation passes the relevant event environment variables to the child process, as documented for Oxidized’s exec hook.

The script should obtain the Teams webhook URL from a secure source and build the payload from validated event metadata.

Using a separate script is preferable to placing a long HTTP request directly in the YAML configuration. It makes the integration easier to test, maintain, secure, and reuse.

7.5 Why Use a Script Instead of a Long Shell Command?

A short shell command may be adequate for a lab test, but it becomes difficult to maintain when it includes JSON escaping, secret handling, retries, error logging, and conditional logic.

A dedicated script can provide:

• Input validation.
• Explicit request timeouts.
• Structured JSON generation.
• Controlled logging.
• Response-code checking.
• Retry handling for temporary failures.
• Secret isolation.
• Consistent formatting across event types.

This separation also makes it easier to test the integration without forcing a new device configuration change every time a message format is modified.

7.6 Test Microsoft Teams Delivery

Test the Teams workflow before enabling production alerts.

1. Send a minimal request directly to the workflow.
2. Confirm that the message appears in the correct destination.
3. Verify that the payload format matches the workflow trigger.
4. Run the notification script manually using safe test values.
5. Trigger a real post_store event in a test environment.
6. Confirm that Oxidized invokes the script.
7. Inspect logs for HTTP errors or execution failures.
8. Verify that the webhook URL is not printed in logs.

A successful HTTP request does not necessarily prove that the message appeared exactly as intended. Validate the final message in Teams.

8. Building a Reusable Notification Script

A reusable script is often the most practical way to connect Oxidized to Teams and can also support Slack when the organization wants a common notification format.

The example below uses Python 3 and the standard library. It sends a basic text notification to a Teams workflow that accepts a JSON object containing text.

It is intentionally designed for a simple event notification rather than publishing a raw configuration diff.

8.1 Create the Script

Save the following as /usr/local/bin/oxidized-teams-notify.

#!/usr/bin/env python3 import json import os import sys import urllib.error import urllib.request def main(): webhook_url = os.environ.get("TEAMS_WEBHOOK_URL") if not webhook_url: print("TEAMS_WEBHOOK_URL is not configured", file=sys.stderr) return 2 event = os.environ.get("OX_EVENT", "unknown") node = os.environ.get("OX_NODE_NAME", "unknown") group = os.environ.get("OX_NODE_GROUP", "unknown") # Do not log the webhook URL or configuration contents. message = ( "Oxidized network event\n" f"Event: {event}\n" f"Device: {node}\n" f"Group: {group}" ) payload = json.dumps({"text": message}).encode("utf-8") request = urllib.request.Request( webhook_url, data=payload, headers={"Content-Type": "application/json"}, method="POST", ) try: with urllib.request.urlopen(request, timeout=10) as response: if not 200 <= response.status < 300: print( f"Teams returned HTTP {response.status}", file=sys.stderr, ) return 1 except urllib.error.HTTPError as exc: print( f"Teams request failed with HTTP {exc.code}", file=sys.stderr, ) return 1 except (urllib.error.URLError, TimeoutError) as exc: # Avoid printing the request URL or other secret-bearing data. print( f"Teams request failed: {type(exc).__name__}", file=sys.stderr, ) return 1 print(f"Notification delivered for event={event}, node={node}") return 0 if __name__ == "__main__": sys.exit(main())

The script reads event metadata from environment variables and sends a JSON request. It does not read or publish the device configuration itself.

The receiving workflow must accept the {"text": "..."} payload format for this example to work.

8.2 Configure Permissions

Install the script with restrictive ownership and permissions.

sudo chown root:root /usr/local/bin/oxidized-teams-notify sudo chmod 755 /usr/local/bin/oxidized-teams-notify

The Oxidized service account can execute the script without being allowed to modify it.

Configure the webhook URL through an appropriate secret-management mechanism. For a simple systemd deployment, this may involve a protected environment file, but the exact method should match the organization’s credential-management standards.

Avoid embedding the URL directly in the script.

8.3 Configure the Hook

Add the following hook to the active Oxidized configuration.

hooks: teams_change_alert: type: exec events: [post_store] cmd: '/usr/local/bin/oxidized-teams-notify' async: true timeout: 30

Preserve existing hooks and settings when editing the configuration. Do not replace the entire configuration file with this example.

Restart or reload the service according to your installation method, then inspect the logs for syntax errors or hook initialization problems.

8.4 Understand the Script’s Limitations

This example is a starting point, not a complete enterprise notification service.

In particular:

• It assumes a Teams workflow that accepts a simple text payload.
• It does not implement retries.
• It does not queue messages during an outage.
• It does not deduplicate repeated events.
• It does not validate the webhook URL against an approved hostname.
• It does not enforce an organization-specific allowlist of devices.
• It does not provide durable delivery auditing.
• It does not publish configuration diffs.

For production use, add the controls that your operational requirements demand.

If delivery must survive Teams outages, a queue or durable event store is more appropriate than repeatedly invoking a script and hoping the next request succeeds.

8.5 Adapting the Script for Slack

Slack incoming webhooks also accept JSON payloads, so the same basic design can be adapted for Slack by changing the destination secret and message formatting.

However, keep platform-specific behavior explicit. Do not assume that every formatting feature supported by Slack is available in Teams, or that both platforms accept identical card structures.

For a simple text notification, a common internal event format can be transformed into the appropriate platform-specific payload.

For example, an internal event might contain:

{ "event": "post_store", "node": "core-sw-01", "group": "core-switches", "change_reference": "approved-repository-reference" }

The actual notification adapter can then map these fields to the Slack or Teams message format.

Use real repository references generated by your environment. The sample reference above is a placeholder, not a valid commit identifier or URL.

9. Designing Useful Configuration Change Messages

A notification integration is only useful if engineers can interpret the messages it produces.

Sending every available field to a collaboration channel is rarely the best solution. Instead, design messages around the operational question the recipient needs to answer.

9.1 Recommended Message Structure

A configuration change notification should normally contain:

1. A clear event heading.
2. The device hostname.
3. The device group or infrastructure role.
4. The event type.
5. A reliable timestamp, when available.
6. A link to the authoritative configuration history, if available.
7. A concise next step.

For example:

Network configuration change detected

Device: edge-rtr-02

Group: edge-routers

Event: Changed configuration stored

Action: Review the latest configuration revision and correlate the change with the approved change record.

This format is intentionally concise. It identifies the device and recommends an investigation path without exposing the complete configuration.

9.2 Separate Change Alerts from Backup Failure Alerts

A configuration change and a backup failure require different responses.

A change alert tells the engineer to review the new revision and establish whether the change was expected.

A backup failure alert tells the engineer that configuration visibility may be incomplete and that the collection problem requires investigation.

Mixing both event types into one generic message can cause confusion.

Use clear event labels such as:

• Configuration changed.
• Configuration collection failed.
• Collection cycle completed.
• Notification delivery failed.

If the environment supports severity levels, assign them based on operational impact rather than simply treating every configuration difference as critical.

9.3 Link to the Source of Truth

The notification should direct engineers to the system that holds the authoritative configuration history.

Depending on the deployment, this may be:

• A Git repository.
• A protected configuration management interface.
• An internal source-control browser.
• A change-management record.
• A ticket associated with the configuration change.

A link should identify the relevant resource accurately. Avoid linking to a generic dashboard when a specific revision is available.

Also ensure that the destination enforces its own access controls. A notification should not bypass the permissions required to view sensitive configuration history.

9.4 Avoid Excessive Configuration Diff Content

Configuration diffs can be valuable, but publishing them directly into collaboration channels introduces risk.

A diff may include:

• Local usernames.
• Authentication settings.
• SNMP community strings.
• VPN parameters.
• Internal IP addresses.
• Firewall policy details.
• Cryptographic material or other sensitive values.

Redaction should happen before the data reaches the destination. Hiding sensitive text visually in a message is not equivalent to removing it from the payload.

A safer default is to send a concise summary and a restricted link to the complete diff.

If inline diffs are required, implement a tested redaction process and verify that it covers the device models and configuration formats used in the environment.

10. Handling Backup Failures and Operational Alerts

Change notifications are only one part of a useful integration. A production deployment should also identify failures that prevent Oxidized from collecting configurations.

10.1 Configure a Backup Failure Hook

The node_fail event can be used to notify the operations team when a device cannot be collected successfully after the configured retries.

For example:

hooks: node_failure_alert: type: exec events: [node_fail] cmd: '/usr/local/bin/oxidized-node-failure-notify' async: true timeout: 30

This configuration assumes that the referenced script exists and has been tested.

The script can use the event metadata available in the installed Oxidized version to produce a message containing the device name and relevant error context.

Do not blindly copy error strings into a public channel. They may reveal internal addresses, usernames, or infrastructure details.

10.2 Distinguish Device Failures from Notification Failures

There are two independent failure domains.

Collection failure: Oxidized cannot retrieve a configuration from a device.

Delivery failure: Oxidized detects an event, but the notification cannot be delivered to Slack or Teams.

These conditions require different remediation.

For collection failures, investigate device reachability, credentials, SSH negotiation, device load, access-control policies, and model compatibility.

For delivery failures, investigate DNS resolution, outbound HTTPS access, proxy configuration, webhook validity, endpoint permissions, rate limiting, and payload format.

An integration that reports only collection failures can still silently lose notifications. Monitor both paths.

10.3 Reduce Alert Noise

Repeated notifications for a device that remains unreachable can overwhelm the operations channel.

Useful noise-reduction strategies include:

• Grouping repeated failures into a single incident.
• Applying a cooldown period.
• Reporting recovery when collection succeeds again.
• Sending detailed diagnostics to logs while keeping channel messages concise.
• Routing device failures to a dedicated operations channel.
• Escalating only after a defined failure threshold.

Implement these controls in a script, queue, or alert-management service rather than assuming that the hook itself provides deduplication or incident-state management.

10.4 Report Collection Health Separately

A nodes_done event can be useful for batch-level reporting, subject to the installed version’s documented behavior.

For example, an external process could summarize the last collection cycle and report how many devices were successfully backed up.

However, the existence of a completed cycle does not automatically provide a reliable success percentage. Accurate reporting requires a trustworthy record of the total expected devices and the outcomes for the relevant cycle.

For larger environments, collect these metrics in a monitoring system rather than relying entirely on chat notifications.

11. Security and Compliance Considerations

Network configuration backups can contain information that would be valuable to an attacker. Notification integrations must therefore be treated as part of the organization’s security boundary.

11.1 Protect Webhook URLs and Tokens

Webhook URLs and API tokens can grant the ability to post messages or interact with a destination.

Protect them as credentials.

Recommended controls include:

1. Store secrets in an approved secret manager or protected service configuration.
2. Restrict access to the Oxidized service account and authorized administrators.
3. Avoid placing secrets in source-control repositories.
4. Prevent secrets from appearing in logs and exception messages.
5. Rotate credentials according to organizational policy and when exposure is suspected.
6. Remove obsolete webhook endpoints and tokens.
7. Document ownership and renewal responsibilities.

If a webhook URL is accidentally published, treat it as compromised and replace it using the destination platform’s supported process.

11.2 Apply the Principle of Least Privilege

The notification mechanism should have only the permissions it needs.

For a simple incoming webhook, that usually means permission to post to a designated destination rather than broad administrative access to the collaboration platform.

Likewise, the Oxidized service account should not receive unrestricted access to the host merely to execute a notification script.

Use dedicated service identities where practical and review permissions periodically.

11.3 Prevent Sensitive Information Disclosure

Never assume that a configuration diff is safe to distribute simply because it comes from an internal network device.

Before publishing any diff:

• Identify sensitive configuration fields.
• Define a redaction policy.
• Test the policy against representative configurations.
• Confirm that secrets are removed before serialization and transmission.
• Restrict access to message history and stored payloads.
• Establish a retention policy appropriate for the data.

The safest default is to send device identity and a reference to the restricted configuration history.

11.4 Restrict Network Egress

A notification host needs outbound connectivity to its configured destination.

Allow only the necessary outbound HTTPS traffic where practical, taking account of DNS resolution, proxy requirements, certificate validation, and any approved inspection infrastructure.

Do not disable TLS certificate verification to work around connectivity problems.

If the environment uses an outbound proxy, configure it explicitly and verify that the notification script uses the intended network path.

11.5 Maintain an Audit Trail

A chat message is not necessarily an adequate audit record.

Messages may be edited, deleted, retained for limited periods, or governed by collaboration-platform policies.

For stronger auditability, maintain a separate record of:

• The detected event.
• The affected device.
• The associated configuration revision.
• The notification attempt.
• The delivery result, where available.
• Relevant timestamps.
• The change-management reference, if known.

Avoid recording secrets or complete configurations in the audit log unless there is a documented requirement and an appropriate protection model.

11.6 Understand the Limits of Notification-Based Compliance

A notification can demonstrate that a system reported a change, but it does not independently prove that the change was authorized.

To support stronger change governance, correlate configuration history with:

• Approved change tickets.
• Administrative login records.
• Centralized authentication and authorization logs.
• Command accounting, where available.
• Peer review or approval records.
• Incident-management records.

Compliance requirements vary by industry and jurisdiction. Map the implementation to the controls that actually apply to the organization rather than claiming that a webhook integration alone establishes compliance.

12. Performance, Reliability, and Scalability

An integration that works with five devices may behave differently when hundreds or thousands of devices are managed.

The main challenge is not necessarily the cost of a single HTTP request. It is the cumulative effect of event volume, collection frequency, network failures, retry behavior, and notification processing.

12.1 Keep Hook Execution Bounded

A hook should not be allowed to wait indefinitely for a remote endpoint.

Use explicit request timeouts and an appropriate Oxidized hook timeout.

Asynchronous execution can reduce the impact of a slow notification process on configuration collection, but it introduces trade-offs. Failures may occur after the main process has moved on, and delivery guarantees depend on the script and execution model.

If notifications are operationally critical, use durable delivery mechanisms rather than relying solely on asynchronous shell execution.

12.2 Use Retries Carefully

Retries can help with temporary network failures and rate limiting.

However, aggressive retries can worsen an outage by increasing traffic to an already struggling endpoint.

A sensible retry strategy includes:

1. A small maximum number of attempts.
2. Exponential backoff.
3. Randomized jitter where appropriate.
4. A clear distinction between retryable and permanent errors.
5. Logging of final delivery failure.
6. A defined process for reprocessing missed events.

For HTTP-based integrations, responses such as 429 Too Many Requests may justify a delayed retry. Authentication failures and malformed payloads usually require configuration correction rather than immediate repeated requests.

A custom script that exits after one failure does not provide reliable retries by itself.

12.3 Consider Message Queues for Large Environments

A message queue can separate event generation from notification delivery.

In this design, Oxidized publishes a compact event to an internal service. A worker processes the event, transforms it for the target platform, and sends the notification.

The queue can support:

• Temporary endpoint outages.
• Controlled concurrency.
• Retry policies.
• Dead-letter handling.
• Centralized observability.
• Multiple notification destinations.
• Event deduplication.

The trade-off is additional infrastructure and maintenance.

A queue is generally unnecessary for a small deployment that generates only a few notifications each day. It becomes more attractive when notification delivery is business-critical or event volume is substantial.

12.4 Prevent Duplicate Notifications

Duplicate alerts can occur when multiple hooks target the same channel, when an event is retried, or when an integration is reconfigured without disabling the previous path.

To reduce duplicates:

• Select one primary notification path for each event type.
• Define a stable event identifier when the source provides enough information.
• Track delivery state where reliable deduplication is required.
• Avoid enabling both a native hook and a custom hook for the same purpose unless duplication is intentional.
• Make downstream processing idempotent where possible.

A hostname and event name alone may not uniquely identify an event. Use a revision identifier or another stable reference when available.

12.5 Monitor the Integration

Monitor the notification path independently of the Oxidized service.

Useful metrics include:

Metric	What it reveals
Configuration collection success rate	Whether devices are being backed up reliably
Number of configuration changes	Whether change volume is unusual
Notification delivery success rate	Whether Slack or Teams requests are succeeding
HTTP error counts	Whether endpoints are rejecting requests
Notification latency	How long events take to reach the destination
Queue depth	Whether delivery workers are falling behind
Retry count	Whether transient failures are increasing
Last successful notification	Whether the integration is still functioning

A basic deployment can use service logs and a periodic test event. A larger deployment should expose measurable health signals through its existing monitoring platform.

Do not use the mere absence of errors in the Oxidized service log as proof that every notification was delivered.

13. Real-World Implementation Scenarios

The right notification policy depends on the organization’s network topology, change-management process, and operational staffing.

13.1 ISP Network Operations Center

An ISP may manage core routers, aggregation switches, access switches, customer-edge devices, and firewalls.

A practical design separates alerts by operational role.

• Core and aggregation configuration changes go to a restricted network engineering channel.
• Access-device backup failures go to the network operations team.
• Security-device changes go to the designated security operations channel.
• Routine status summaries go to a lower-priority reporting destination.

This structure helps engineers focus on relevant events.

For an ISP, configuration history is particularly useful when investigating routing changes, VLAN modifications, trunk updates, access-control changes, and customer-service incidents.

The notification itself should not be treated as proof that a change caused an outage. Engineers should correlate the revision timestamp with monitoring data, interface counters, routing events, and the applicable change ticket.

13.2 Enterprise Campus Network

A large enterprise may have distribution switches, access switches, wireless controllers, branch routers, and perimeter firewalls.

In this environment, a single notification channel can become noisy.

A better approach uses device groups and routing rules to send messages to the appropriate teams.

For example, changes to campus switching infrastructure may be routed to the network engineering team, while firewall changes go to a security-focused destination.

Keep the mapping between device groups and notification destinations under version control where practical, and review it whenever the network inventory changes.

13.3 Managed Service Provider

An MSP may manage multiple customer environments using a shared Oxidized deployment or several separate instances.

Customer isolation is essential.

A shared notification service must not send one customer’s configuration details to another customer’s channel. Destination selection should be based on a controlled inventory mapping rather than an unvalidated device-supplied field.

Use separate credentials and restricted destinations where the risk profile or contractual requirements justify them.

Where customer isolation is especially important, separate instances or isolated processing boundaries may be preferable to a single shared integration.

13.4 Security and Firewall Operations

Firewall configuration changes can have immediate consequences for network exposure and traffic flow.

A notification can help the security team identify a change to access-control rules, NAT policies, VPN configuration, or management-plane settings.

However, Oxidized does not inherently know whether a change is malicious or authorized.

A robust process correlates the detected revision with change tickets, administrator identities, device logs, and security monitoring events.

A configuration change without a corresponding approved change record can be flagged for review, but automated systems should account for emergency changes, maintenance windows, and differences in the organization’s approval process.

13.5 Lab and Development Environments

For a small lab, a simple exec hook and incoming webhook are often sufficient.

A lab deployment is an excellent place to validate:

• Hook syntax.
• Event behavior.
• Script permissions.
• Payload formatting.
• Endpoint authentication.
• Failure handling.
• Message clarity.

Once the workflow is stable, the same design can be adapted to production with stronger secret management, monitoring, retry controls, and access restrictions.

Avoid promoting a lab script directly into production without reviewing its logging, credential storage, error handling, and operational dependencies.

14. Troubleshooting Common Problems

Troubleshoot the integration one layer at a time. First verify configuration collection, then event generation, then script execution, and finally destination delivery.

14.1 No Notification Appears

Possible causes include:

• No configuration change was detected.
• The post_store event was not triggered.
• The hook configuration contains a syntax error.
• The hook dependency is missing.
• The script is not executable.
• The service account cannot access the required secret.
• The endpoint is unreachable.
• The destination rejects the payload.

Use this workflow:

1. Confirm that Oxidized collected and stored a changed configuration.
2. Review the service logs.
3. Verify that the hook is loaded and associated with the intended event.
4. Test the script independently with safe input.
5. Test the endpoint using a minimal payload.
6. Confirm that the final message appears in the intended channel.

Do not start by replacing the webhook URL. Identify the failing layer first.

14.2 The Slack Hook Fails to Load

Check the installed Oxidized version and the dependency required by that version’s slackdiff implementation.

A dependency installed for a different Ruby environment may not be visible to the Oxidized process.

Investigate:

1. The Ruby interpreter used by the service.
2. The installed Slack client dependency.
3. Gem paths and package-management boundaries.
4. The hook configuration syntax.
5. Slack token validity.
6. Channel identifier and access permissions.
7. Compatibility between the output backend and diff functionality.

Avoid repeatedly installing different gems until the configuration appears to work. Establish which dependency the installed hook actually requires.

14.3 Microsoft Teams Rejects the Request

The most likely causes are an incorrect endpoint, an unexpected payload format, an authentication mismatch, or a workflow that is disabled or no longer available.

Check the response status and the workflow configuration.

A successful request requires agreement between the sender and receiver on the expected payload structure.

If the workflow expects an Adaptive Card, a plain-text payload may not work. If the workflow requires a particular authentication method, simply possessing its URL may not be sufficient.

Test the endpoint with a minimal request that matches the configured trigger before modifying the Oxidized hook.

14.4 The Script Works Manually but Fails Under Oxidized

This often indicates a difference between the interactive shell and the service environment.

Potential causes include:

• Different environment variables.
• Different user permissions.
• A missing executable path.
• A protected secret file that the service account cannot read.
• Different DNS or proxy behavior.
• A different Python interpreter.
• A restrictive service sandbox.
• A timeout that is too short.

Run the script as the Oxidized service account using the deployment’s normal execution environment.

Do not solve permission problems by running Oxidized as root without a clear security justification.

14.5 The Notification Contains Empty Device Fields

If the message shows an unknown hostname or empty group, inspect the environment variables provided by the hook for the event in question.

Not every event necessarily provides the same metadata.

Test the exact event and installed version. Do not assume that a variable is always populated simply because it appears in the documentation.

If a field is unavailable, use a reliable alternative or omit it rather than inserting misleading information.

14.6 Configuration Diffs Are Missing

For the native Slack diff hook, confirm that the configured output backend supports diff generation and that the required history exists.

Also verify that:

• The event is post_store.
• The hook is configured to publish diffs.
• The integration dependency loads correctly.
• The repository contains the expected revision.
• The selected device was actually changed.

A message without a diff does not necessarily indicate that the integration is broken. It may reflect a deliberate configuration setting or a backend limitation.

14.7 Too Many Notifications Are Generated

Check whether multiple hooks are configured for the same event or whether the notification system is reporting successful polls instead of actual changes.

Review:

1. Hook event selections.
2. Duplicate Slack and Teams delivery paths.
3. Any custom polling or event-forwarding scripts.
4. Retry behavior.
5. Whether unchanged configurations are being treated as changes.
6. Whether a broad event such as node_success is being used unnecessarily.

For high-volume environments, introduce event filtering, grouping, and deduplication at the notification layer.

14.8 Notifications Stop After a Credential Rotation

Credential rotation can invalidate an existing webhook or API token.

After rotation:

1. Update the secret in the approved storage location.
2. Confirm that the service account can read the updated value.
3. Restart or reload the affected process if required.
4. Send a controlled test notification.
5. Verify successful delivery.
6. Remove obsolete credentials according to policy.

Document the credential owner and renewal procedure so the integration does not depend on undocumented personal knowledge.

14.9 Useful Diagnostic Commands

The following commands can help isolate common problems on a systemd-based Linux installation.

Check service status:

sudo systemctl status oxidized

Inspect recent logs:

sudo journalctl -u oxidized -n 200 --no-pager

Check script permissions:

ls -l /usr/local/bin/oxidized-teams-notify

Check whether the expected Python executable is available:

command -v python3 python3 --version

These commands are diagnostic examples. Adapt paths and service names to the actual deployment.

Avoid printing secret-bearing environment variables or enabling verbose HTTP debugging in production if the resulting logs could expose credentials.

15. Best Practices and Implementation Checklist

A successful integration should be easy to operate, safe to maintain, and understandable by the people who depend on it.

15.1 Before Deployment

• Confirm the installed Oxidized version.
• Verify that device configuration collection works.
• Confirm that configuration history is stored correctly.
• Select the notification events required by operations.
• Choose a native hook or custom webhook approach.
• Create a dedicated test channel or chat.
• Confirm the destination’s supported payload format.
• Identify where secrets will be stored.
• Define which device groups should generate notifications.
• Establish a safe test plan.

15.2 During Deployment

• Use the documented hook syntax for the installed release.
• Keep scripts separate from the main Oxidized configuration where practical.
• Restrict script modification permissions.
• Set explicit HTTP and hook timeouts.
• Avoid embedding secrets in shell commands.
• Validate JSON payloads.
• Test successful changes and failed collections separately.
• Confirm that unchanged configurations do not generate misleading alerts.
• Check that notification messages contain no sensitive configuration data.
• Confirm that the destination receives the message as expected.

15.3 After Deployment

• Monitor hook execution and delivery errors.
• Review notification volume.
• Verify that the last successful notification is observable.
• Document credential rotation.
• Review destination permissions.
• Test the recovery process after a temporary endpoint outage.
• Review script compatibility after Oxidized or runtime upgrades.
• Maintain workflow ownership and co-ownership where supported.
• Periodically verify that links to configuration history remain valid.
• Update operational documentation when the integration changes.

15.4 Recommended Operational Ownership

Assign clear ownership for each component.

Component	Suggested owner
Oxidized service and collection	Network engineering or infrastructure operations
Device inventory and model configuration	Network engineering
Git or other configuration history	Infrastructure or configuration management team
Slack application and destination	Collaboration platform administrator
Teams webhook workflow	Microsoft 365 or Teams workflow owner
Notification script	Infrastructure automation team
Secret management	Security or platform operations
Monitoring and incident escalation	Network operations or SRE

In smaller organizations, one team may own several components. The important point is to ensure that every operational dependency has an accountable owner.

16. Frequently Asked Questions

16.1 Can Oxidized Send Configuration Change Alerts to Slack?

Yes. Oxidized documents a slackdiff hook that can publish configuration diffs when the post_store event occurs. It requires the appropriate dependency, credentials, compatible configuration output, and correct hook configuration. A custom Slack incoming webhook script is another option when a simpler or more customized message is preferred.

16.2 Does Oxidized Have a Native Microsoft Teams Hook?

The documented slackdiff hook is Slack-specific. A common approach for Microsoft Teams is to use Oxidized’s generic exec hook to run a script that sends an HTTPS request to a supported Teams webhook workflow. Confirm available hooks in the documentation for the installed Oxidized release.

16.3 Which Oxidized Event Should Trigger Configuration Change Alerts?

Use post_store for notifications about changed configurations that have been stored. Use node_fail for collection failures. These events represent different operational conditions and should normally produce different messages.

16.4 Does Oxidized Send an Alert Every Time It Polls a Device?

Not necessarily. A successful poll does not automatically mean that a configuration changed. The post_store event is associated with a stored configuration change. Verify the behavior of your installed version and output backend when testing.

16.5 Can Slack or Teams Show the Actual Configuration Diff?

Yes, subject to the integration’s capabilities, payload constraints, and security requirements. The native Slack diff hook supports configuration-diff notifications when the output backend is compatible. A custom integration can also publish a diff, but the script must implement that behavior.

For sensitive production configurations, a concise alert linking to a restricted revision is often safer than placing the entire diff in a chat message.

16.6 Do I Need Git for Oxidized Notifications?

Not for every type of notification. A basic event notification can report that a configuration changed without including a Git link. However, the native Slack diff integration requires a compatible output capable of generating diffs. Git-based storage is a common option when revision history and change comparisons are required.

16.7 Can Oxidized Notify Me When a Backup Fails?

Yes. The node_fail event can be used to invoke a script or another supported hook action. The resulting notification should identify the affected device and provide enough context for troubleshooting without exposing credentials or unnecessary infrastructure details.

16.8 Are Incoming Webhook URLs Secure?

They should be treated as sensitive credentials because possession of a URL may grant permission to post messages to its destination. Store the URL securely, restrict access, avoid logging it, and replace it if exposure is suspected. Follow the authentication requirements of the selected Slack or Teams integration.

16.9 Can I Send Notifications to Both Slack and Microsoft Teams?

Yes. You can configure separate hooks or use a common notification service that sends the same internal event to both platforms. Choose one clearly defined delivery path for each destination and avoid enabling duplicate integrations that publish the same message twice.

16.10 Will Notifications Arrive Immediately After a Network Change?

They can arrive shortly after Oxidized detects and stores the change, but not necessarily at the moment the device is modified. Detection depends on the polling schedule and collection duration. Network delays, endpoint availability, rate limits, and workflow processing can add further latency.

16.11 What Happens If Slack or Teams Is Unavailable?

The result depends on the hook implementation and notification script. A simple script may fail and exit without durable delivery. More resilient implementations use bounded retries, a queue, or another durable event mechanism to recover from temporary outages.

Do not assume that asynchronous execution guarantees delivery.

16.12 Can Oxidized Identify Who Changed a Device Configuration?

Not inherently. Oxidized detects and stores configuration differences, but attribution requires correlation with device authentication logs, administrative command accounting, AAA systems, and change-management records.

16.13 Should I Publish Complete Configuration Files in Slack or Teams?

Usually not. Complete configurations and diffs may contain sensitive operational information. A concise alert with a link to a restricted configuration repository is a safer default. If inline diffs are necessary, apply and test redaction before sending the content.

16.14 Is a Custom Python Script Better Than a Native Hook?

Neither option is universally better. A native hook may be simpler for a supported integration such as Slack diff notifications. A Python script provides flexibility for Microsoft Teams workflows, custom message formatting, and common integrations, but it introduces maintenance and reliability responsibilities.

Choose the smallest design that meets the actual operational requirements.

16.15 How Can I Prevent Alert Fatigue?

Notify on meaningful events, separate configuration changes from backup failures, route alerts by device group, suppress repeated failures where appropriate, and keep routine messages concise. Reserve urgent notifications for events that genuinely require immediate attention.

17. Expert Recommendations and Key Takeaways

A well-designed Oxidized notification system improves visibility into network changes without turning collaboration channels into a stream of unfiltered infrastructure events.

For most deployments, the following recommendations provide a practical starting point.

1. Use the correct event for the job. Use post_store for configuration changes and node_fail for failed collections. Do not equate a successful poll with a configuration change.

2. Start with the simplest supported integration. If the native Slack diff hook meets the requirement, use it. For Microsoft Teams or more customized workflows, use the exec hook with a dedicated script.

3. Test the receiving endpoint independently. Validate the payload and workflow before involving Oxidized. This separates webhook problems from configuration collection problems.

4. Keep secrets out of the message and logs. Treat webhook URLs, API tokens, and configuration content as sensitive. Use approved secret-management practices and least-privilege access.

5. Separate change alerts from collection failures. These events require different troubleshooting steps and often belong in different notification channels.

6. Link to authoritative configuration history. A message is most useful when engineers can locate the exact stored revision. Ensure that links point to real resources and enforce appropriate access controls.

7. Make delivery failures observable. Monitor the notification integration independently. For business-critical alerts, use durable queues or another mechanism that supports recovery from downstream outages.

8. Avoid unnecessary complexity. A small environment may need only one hook and a short script. Add queues, filtering services, multiple destinations, and advanced deduplication only when operational requirements justify them.

9. Review the integration after upgrades. Oxidized hooks, Ruby dependencies, Slack APIs, and Microsoft Teams workflows can evolve. Test the integration whenever a relevant component changes.

10. Treat alerts as evidence of a detected change, not proof of authorization or causation. Correlate configuration history with approved changes, device logs, monitoring events, and incident records before drawing conclusions.

The practical goal is not simply to send more notifications. It is to make important network configuration changes visible, understandable, and actionable.

With an appropriate hook, a secure webhook endpoint, a carefully designed message format, and a tested delivery process, Oxidized can become a useful part of a broader network change-management workflow.