Since the launch of Kentik NMS a few years ago, Alerting has become an increasingly important part of how our customers use Kentik every day. And as we've expanded our visibility into network health with device-level metrics, syslog records, SNMP traps, and other telemetry, we've also expanded the range of conditions customers can monitor and alert on.

That's a good thing of course, but it also created conditions where alerting became more noisy and hard to manage -- which runs opposite our goal of providing network intelligence that provides clarity of insight and action.

As such, we are kicking off a series of improvements to make Kentik Alerting simpler to manage, less noisy, more automated and AI-assisted. Today we release the first phase of those improvements around managing alert noise with a substantial overhaul of Alert Supressions. 

TL;DR: Suppressions are now more flexible, easier to configure, faster to activate, and capable of working across different types of alerts. Read on for more.

Overview of the changes

There are three key aspects to today's post. I cover each in more detail below, but here is a quick summary: 

1: "Silencing" is going to be phased out. 

"Silencing" was initially built to prevent notifications from being generated and sent - "Suppressions", by contrast were used to avoid triggering an alert when the policy's conditions were met.

Existing "Silencing" instances will still be honored, but no new ones can be created from now on.

2: Suppressions are now the main and only concept

Under this new functionality, "Suppressed Alerts" still exist, get triggered and are stored in our SaaS cluster - in other words, there's now an attribute of every Alert Instance that indicates if it's Suppressed.

A suppressed Alert:

• Is not visible (at current) on the Alerting Landing Page
• Does not generate any notification, even if a notification channel is attached to its policy

3. Introducing Structured Alert Context

This specific feature is the one that packs the punch.

Previously, suppressions were tied to the keys defined in individual Alert Policies. If you wanted to be able to suppress alerts for a particular device or site, those attributes needed to be included as keys in each underlying policy at the policy level. And if you wanted to suppress different types of alerts, such as Traffic, NMS, or Events, you'd need to configure separate suppressions for each. This became burdensom to manage and configure across large, complex environments. 

Those days are over. 

Structured Alert Context introduces a new, common set of contextual attributes associated with every alert as its generated. Each alert producer (Flow, NMS, Syslog and SNMP Traps, Synthetics, etc.) enriches this context with relevant information about the alert, independent of the keys configured in its Alert Policy.

This means that the new Supressions engine can evaluate rules against a common set of context regardless of the alert or policy that generated it. 

For instance, let's say you're performing maintenance at a particular site. You can now create a single Suppression Rule that matches alerts associated with that site, whether they originate from Traffic, NMS, Events, or other supported sources -- without having to add the specific site keys associated with the actual policy that fires. 

4. Faster Time-to-Action

This one is simple enough -- we've drastically improved the speed at which suppressions take place. In the past, a 20min delay stood between the creation of a suppression rule and the moment at which it actively started suppressing new matching Alerts: this is not the case anymore. In our preliminary testing, newly created suppression rules were active in under a minute.

Feature tour

Okay -- let's see how this works via some product screenshots! 

First-off, Alert Suppression Rules are Named and come with a Comment field, so that users who haven't configured these can still understand which ones are ongoing or planned.

Another important aspect is that while we're still honoring ongoing suppressions that have been configured with the Legacy Model, no new one can be created moving forward, as we believe this new paradigm better serves our customers.

New Suppression Rules status

Let's go to Settings > Suppressions & Silences as this is where the new features start.
You will notice that we've added the notion of Suppression Status in the Suppressions Listing Table and associated left-side filter panel: 3 statuses are now available:

• Planned
  where both Suppression Start Time and End Time are in the future
• Ongoing
  where Suppression Start Time is in the past, and Suppression End Time is in the future
• Expired
  where both Suppression Start Time and End Time are in the past

These statuses go with the following rules:

• Planned suppressions can be fully Created/Edited/Deleted (unless they are legacy suppressions/silences)
• Ongoing or Expired suppressions cannot be Created/Edited/Deleted
• Ongoing suppressions can be stopped 

See how these statuses appear in the screen's filter bar - note that by default we're only showing Planned and Ongoing Suppression Rules.

A much more flexible suppressions creation experience

A complete overhaul of the Suppressions configuration UX has been released, it replaces the previous one.

Side note:
This new UX is also designed to be compatible with previous types of suppressions - our users using the current suppressions API (which hasn't yet been updated) will have their API-created suppressions still valid and visible in the UX - editable if they belong to the Planned bucket.

Legacy Suppressions Configurations leverage the Alert Dimension-Specific Filters. We built this new UX to be retro-compatible with the existing suppressions.
Remember that those legacy suppression configs are entirely dependent on the Keys defined in the Alert policy.

The new, standard Alert Suppression Rules can include both factors from Matching Criteria (the new fields applied to any type of Alerts) and Alert Dimension-Specific Filters both sections are AND'ed together as we evaluate which Alert gets suppressed upon instantiation.

These new Alerts can be scoped by Severity (Info, Warning, Critical...), Applications (Traffic/Flow, Protect, NMS/Event, Synthetics...) or Policy.

Note
Unless the Applications attribute is set to a list in the configuration dropdown, they by default apply to all types.

More flexible Suppression Criterias

A closer look at the "Filters" section of the "Matching Criteria" panel shows we can now build suppressions based on:

• A flexible, nested set of OR and AND conditions that feed off the Structured Context to determine which alerts need to be suppressed upon generation
• more flexible Filter conditions to capture broad sets of Alerts to suppress that have been commonly reported as needed by our users:
  • Ex: various string matching functions on "Device Name" or "Site Name" - including "String Contains" or "String Matches Regex"

Here's a view of what an intricate filter can look like:

Ability to test suppressions before setting them live

As a user is configuring suppressions in the new UX, they are now able to see how the suppression would behave on existing Alerts: this is done via the right-side panel.
The underlying idea is that users need a short feedback loop before enabling a Suppression Rule to be able to understand whether is it either too narrow or too broad otherwise the suppression creation process is known to be a wild guess.

Hitting Refresh after changing the matching criterias will re-initiate matching agains the existing alerts populated in the preview screen.

Note
A cooldown timer kicks in upon refresh to protect the backend systems from being swarmed by refresh requests - this limitation will be lifted in the future as we are currently working on scale improvements that will make it unnecessary.

Users can tailor the preview results by choosing which timespan to evaluate existing alerts for and preview on. In addition, they can select whether they want to show

• all Alerts, highlighting the ones that would be suppressed with the configured filter
• only the alerts which would be suppressed with the configured filter

Easy shortcuts to create Alert Suppression Rules

A number of Kentik Portal screens have been updated to allow simpler suppressions creation/configuration that do not require starting from the [+ Add Suppression] screen.
This is intended to support workflows where users want to create a simple/routine suppression such as for a point device, or an entire site.

Here are some good examples:

Creating a suppression rule for a point device directly from the device listing screen

Creating a suppression directly from the Device Details screen of a specific device

Creating a single bulk suppression for a group of Devices directly from the Device Listing Screen

Creating a suppression for an entire Site or set of Sites directly from the Site Listing screen

Creating a suppression for an entire Site, directly from the Site Details screen

This announcement says Phase1, what goes into Phase2 ?

As you can notice, this is just the beginning of a broader project aimed at generally improving the signal to noise ratio of the Alerting product.

We're already planning the next phases of it, which will include:

• Additional Filtering Options to configure the Suppressions Rules (like Interface Classification attributes, Collection Agents a device depends on to export its telemetry and such...)
• Automatic, dependency-based creation of Suppressions, such as when a device goes down, then all of the Alerts for its interfaces, sessions... so to be automatically suppressed
• A major overhaul of the Alerting Landing Page experience
  • for users to be able to visualize suppressed Alerts the same way they are visualizing existing ones
  • "big number" kind of stats that show users how efficient the Suppression system is, or to easily detect if a newly created suppression is suppressing more Alerts than initially intended.
• Programmatic ways to register suppressions/maintenances
  • updating the existing legacy suppressions API and/or creating a new one compatible with this newer method
  • using AI Advisor to instantiate new Suppression Rules based on a prompt

We have had a lot of customers asked for this feature in the past and we genuinely think this update satisfies their expectations - we'd love to hear what you think!

We'd also love to hear from you and what you believe should be the next evolutions of our Alerting Platform: we have a lot of other projects currently on our drawing board that we're excited to share with you, so stay tuned.

Customize Your Alerts: Plain-Text & Template Editing for Email 📧

We’re giving you more control over how your team receives critical information! We know that every workflow is different. Sometimes you need a rich, detailed notification, and other times you need a lightweight, no-frills message that fits perfectly into your existing scripts or mobile devices.

That’s why we’ve upgraded the Email Notification Channel to be more flexible and customizable than ever.

📝 What’s New?

• Plain-Text Format Support: You can now specify that emails be sent in a clean, plain-text format. This is perfect for ensuring compatibility with legacy systems, pager services, or internal tools that parse incoming mail without the overhead of HTML.
• In-line Template Editor: No more "one size fits all" notifications. Use our new in-line editor to fully customize both the email subject and the body.
• Dynamic Data Injection: Tailor your messages using variables from your alert policies—like Alert ID , Severity , or Dimensions —so the most important info is front and center.

💎 Why You’ll Love It

• Parse with Ease: Plain-text emails are a dream for automation. If you use custom scripts to trigger secondary actions based on Kentik alerts, this update makes your life much simpler.
• Reduced Noise: By customizing the subject line, you can help your team identify the priority and source of an alert at a glance, right from their lock screen.
• Branding & Context: Use the body editor to add internal links, SOP instructions, or specific team context, ensuring that whoever receives the alert knows exactly what to do next.

🚀 Tackling Alert Fatigue: Auto-Clear is Here for NMS Event Policies!

Managing network health just got a whole lot smoother. We know how much you love staying on top of your infrastructure, but we also know that manual cleanup can be a drag. That’s why we’re excited to introduce Rolling Window Auto-Clear for Event Alert Policies. This means that NMS syslog and trap alerts have the option for automatic closure after a configurable period of time.

What’s New? ✨

Previously, cleared alerts required specific policy conditions to be met or manual intervention to tidy up your dashboard. Now, within your Event Alert Policies, you can set a custom rolling window that tells Kentik: "If this issue hasn't popped back up in X minutes, go ahead and clear it for me."

• Set it and forget it: Define a specific period of inactivity (e.g., 20 minutes) after which an alert will automatically move from Active to Cleared. 
• Intelligent Tracking: The system monitors the "counter" for your policy conditions; if they aren't met within your specified window, the alert clears itself. 
• Visual Confirmation: You’ll see these transitions reflected in your Up/Down Visualizations with a handy green checkmark showing exactly when the system took care of the cleanup. 

Why You’ll Love It 💎

• Declutter Your Dashboard: Keep your Alerting Page focused only on the issues that actually need your attention right now. 
• Reduced Alert Fatigue: No more "ghost" alerts hanging around after a brief blip has already resolved itself.
• Operational Efficiency: Save those precious clicks for deep-diving into performance data instead of manually acknowledging or clearing minor events. 

Ready to Streamline? 🛠️

Head over to your Manage Alert Policies page to start adding auto-clear windows to your event alert thresholds! 

Hey Kentik Users!

We've heard you, and we're excited to announce a small-but-mighty quality-of-life update for your Alerting page! Say goodbye to manual refreshes and hello to the latest alerts, delivered automatically!

What's New?

You can now select a refresh frequency directly on the Alerting page! We've added new refresh rate options—1, 2, or 5 minutes—that will cause the page to periodically reload and pull in the most recent alerts automatically. 

Why This Matters for You

This feature is a game-changer for anyone who needs eyes on the latest network health status, especially your NOC and SOC teams! 

• Real-time Visibility: Automatic reloading means you're always looking at the freshest data without lifting a finger, ensuring you catch critical events as soon as they happen. 
• Operational Efficiency: Free up your operators' attention from hitting the refresh button so they can focus on what matters: analyzing and responding to the alerts! 

This update is all about making your workflow smoother and ensuring your teams can receive the most recent alerts automatically. 

Head over to the Alerting page today and set your preferred refresh rate! Let us know what you think—we're always working to make your Kentik experience better! 

We're thrilled to announce a major granularity enhancement to Role-Based Access Control (RBAC) in Kentik. Gone are the days of broad, level-based access for Kentik Alerting and Protect. Build custom roles to define exactly who can create, view, update, or delete your critical alert policies, notification channels, and DDoS mitigations.

What's New?

We've rolled out a comprehensive set of permissions and custom roles specifically for Alerting and Protect. This update moves these modules into our modern RBAC framework, replacing the legacy user-level system for these features. 

You can now create custom roles with specific permissions for:

• Alerts: Control who can read, acknowledge, or clear alerts. 
• Alerting Policies: Manage permissions for creating, reading, updating, and deleting policies. 
• Notification Channels: Define who can create, read, and update notification channels. 
• DDoS Mitigation: Assign precise control over who can create, view, start, stop, and delete mitigations. 
• BGP Announcements: Manage who has the ability to view or withdraw BGP announcements. 

Why It Matters

This is a huge step forward for security and operational efficiency. By creating custom roles, you can ensure your team members have exactly the access they need to do their jobs.

• Enforce Least Privilege: Grant NOC operators the ability to acknowledge alerts without letting them change policies.
• Delegate with Confidence: Allow your network security team to manage mitigations without giving them full administrator access to your entire Kentik account.
• Streamline Workflows: Create roles like "Mitigation Authors" or "Alerting Policy Viewers" to match your team's specific responsibilities. 

Take control of your user permissions today!

Ready to fine-tune your team's access? Administrators can head over to the Manage RBAC Roles page in your Organization Settings. From there, you can click "+ Create a Role" to start building your own custom roles with these powerful new permissions! 

Your existing permissions within Alerting and Protect were all migrated to this new RBAC schema and existing role access will be unaffected by this update.

We're excited to see how you use these new controls to secure and streamline your network operations. As always, let us know if you have any feedback!

Hello Kentik Users

Ever felt like you were searching for a needle in a haystack of alerts? We get it. When you need to find a specific alert, you need to find it now. That's why we're thrilled to announce a massive power-up to the search bar on the Alerting page!

What's New?

Previously, your search was limited to the Alert Policy name and its dimensions. While useful, we knew it could be better. You can now use the search bar to find alerts based on any information contained within the alert details.

Just type what you're looking for, and we'll scan everything. This includes, but is not limited to:

• Site names or geographic locations
• NMS device details like manufacturer or model
• Alert Policy labels
• Specific IP addresses, ASNs, or tenants
• Mitigation IDs or Alert IDs

Why You'll Love It 

This enhancement is all about speed and precision, helping you slash the time you spend managing alerts.

• Find What You Need, Faster: No more clicking through complex filter combinations. Instantly pinpoint the exact alerts you're looking for with a simple text search.
• Deeper, Quicker Investigations: Need to find all "Critical" alerts from your "Cisco" routers in the "Ashburn" site? Just type it in. Troubleshooting has never been this easy.
• Improved Workflow: Spend less time hunting and more time resolving. This intuitive search experience streamlines your entire incident response process.

Jump into the Alerting page today and take the new, supercharged search for a spin.

Happy searching!

Hey, Kentik community! 👋

Many of you told us that managing alerts can feel too manual, fragmented across tools, and noisy with unnecessary notifications. We've listened to your feedback and have expanded our capabilities to provide you with more granular control over your alerting environment with the launch of Alerting API v6! This new version is available through REST endpoints and gRPC RPCs, extending the existing Alerting API features. That means you can plug alerting directly into your existing workflows and systems, so automation and integration happen where you already work. Enable your teams with automation, cut down on alert fatigue, and gain clearer visibility into your mitigations with this new update. 

What's the Value?

These new capabilities provide you with unprecedented automation and control, saving you time and effort. With Alerting API v6, you can:

• Automate your incident response: Integrate Kentik Alerting with your existing tools to automatically create tickets, trigger scripts, or execute other actions when an alert fires.
• Enhance network visibility: Get real-time, programmatic access to the status of your alerts and mitigations, giving you a clear picture of your network's health.
• Reduce alert fatigue: Use the new silence and suppression features to fine-tune your alerting policies and reduce unnecessary notifications, so your team can focus on what matters most.

What's New?

The new V6 Alerting API is a huge leap forward, offering a comprehensive suite of new methods to streamline your alerting workflows. Beyond the ability to manage alerts, you can now programmatically control the entire alert lifecycle, from suppression to mitigation.

Here's a look at some of the exciting new features:

• List alerts or a single alert: Get a complete overview of all your alerts or drill down into the details of a specific one to investigate and troubleshoot.
• List policies: Pull a list of all your alerting policies to keep a pulse on what's configured in your environment.
• List mitigations: See all active, inactive, and failed mitigations to ensure your network is protected.
• List mitigation methods and platforms: Gain a full view of your mitigation infrastructure, including all available methods and platforms.
• Create a manual mitigation: Start a manual mitigation programmatically without needing to use the Kentik portal.
• Create, update, and delete silences and suppressions: Take control of alert notifications by creating, updating, or deleting silences and suppressions to prevent unwanted noise during maintenance windows or other planned events.
• Acknowledge and clear an alert: Programmatically acknowledge an alert to let your team know you're on the case and clear it once the issue is resolved.

Check out the  API Tester section of the portal to see all the new v202505 Alerting endpoints!  

🔓 Unlocked: More Power and Flexibility for Custom Webhook Headers!

Get ready to level up your integrations! We've heard your feedback and have supercharged our Custom Webhook notification channels. Gone are the days of being restricted in how you format your headers.

Previously, Custom Headers were limited to 

Authorization and headers prefixed with x-. We're excited to announce that we've removed this limitation, giving you far more freedom and flexibility!

What's New?

We've enhanced our Custom Webhook notifications to support a much broader range of HTTP headers. You can now send notifications with virtually any custom header required by your third-party systems, internal tools, and automation scripts. The only headers we restrict are standard ones that could conflict with the HTTP connection itself.

This means you can now seamlessly integrate with services that require specific header formats for authentication, routing, or metadata without needing complex workarounds.

Why It Matters

This update is all about making your life easier and your integrations more powerful.

• Ultimate Flexibility: Integrate Kentik alerts with an even wider universe of applications and services. If your endpoint needs a X-Custom-Auth-Token, My-App-Identifier, or any other unique header, you can now add it directly.
• Streamlined Automation: Simplify your incident response playbooks. Send alerts with the exact headers your systems expect, making your custom scripts and downstream tools more robust and easier to maintain.
• Enhanced Security: Securely pass custom API keys, tokens, or other authentication data in the precise header format required by your infrastructure.

Get Started!

Putting this new flexibility to work is easy:

1. Navigate to 
   Settings > Notification Channels in the Kentik portal. 
2. Click 
   Add Notification Channel and select 
   Custom Webhook, or edit an existing webhook channel by clicking the pencil icon.
3. In the 
   Custom Headers section, click the + Add button and input any key-value pair you need for your custom headers. 

That's it! We can't wait to see the powerful and creative integrations you build with this new capability. Happy automating!

Feature Overview

Adding event ingestion for real-time alerts and deeper network understanding

We’re excited to announce that Kentik NMS now supports SNMP Traps and syslog ingestion, giving network teams even greater flexibility and insight when managing modern infrastructure.

With this release, Kentik NMS adds support for two of the most widely used protocols for real-time network event communication. Whether it’s a hardware failure, interface status change, or critical software log message, you can now capture, query, and alert on these events natively within Kentik.

🛰️ SNMP Trap Support

SNMP Traps are a cornerstone of traditional network monitoring, allowing SNMP-enabled devices to push events without waiting for polling intervals. With Kentik’s SNMP Trap integration, you can:

• Receive SNMP Traps in real-time
• Filter and search trap events by name and OID
• Receive policy-based alerts and notifications
• Visualize trap events alongside other telemetry for faster root cause analysis

📜 Syslog Ingestion

Syslog messages are vital for capturing detailed system-level events across a wide range of devices. Kentik NMS now ingests and parses syslog data, enabling you to:

• Collect syslog events from routers, switches, firewalls, and servers
• Filter and search syslog events by name, severity, and message content
• Create alerts and notification policies based on syslog messages
• Visualize syslog events alongside other telemetry for faster root cause analysis

Why This Matters

These new ingestion capabilities allow network operators to centralize and correlate even more telemetry within a single observability platform. Whether you're troubleshooting outages, proactively monitoring infrastructure health, or securing your environment, Kentik NMS now has the signal coverage you need.

Key Workflows

Data Explorer

Query/browse traps and syslog events in Data Explorer:

Alerting

You can also bring your query context forward from Data Explorer into NMS's alert policy workflow to alert and send notifications when specific event conditions are met.

For example, let's say we're really interested when an SNMP traps of type "ciscoConfigManEvent" shows up. From the "Add NMS Alert Policy" workflow, we start by selecting a "Policy Type" of "Event" and then an "Event Type" of "SNMP Trap".

 
We then create an alert condition that will trigger a Major alert when a trap arrives of type "ciscoConfigManEvent", and configure a notification to email the interested parties when it occurs.

It's that easy.

Operability

We've also included some admin views to assist in troubleshooting and setup of the SNMP Trap and Syslog Server capabilities on the Universal Agent.

Feature Requests & Bugs

This is a new feature and we're actively seeking your feedback and ideas to make it better. Reach out through your customer success rep or directly to the Kentik NMS Product Manager (Jason Carrier, jcarrier@kentik.com) if you'd like to influence our future development.

Feature Overview

NMS's device-centric alerting now includes the ability to use nested condition groups and Boolean logic when creating alert trigger conditions. 

Trigger logic using operators (ANY, ALL, or NONE) can now be combined and nested, which provides several key advantages, including:

1. More precise control over alert policies
2. Reduced alert noise
3. Better automation potential

This allows policy creators extremely granular control over determining what conditions cause an alert to fire, keeping focus on the alerts that are most meaningful to you, and minimizing noise. 

Here's what the starting alert conditions section looked like before:

And here it is now:

You'll notice you can now add "Condition Groups" and "Nested Condition Groups". These condition groups provide for Boolean logic in the alert trigger conditions - making Kentik NMS significantly more effective at managing complex network environments.

Key Workflows

Condition Groups

Condition groups are the "top level" layer. They can contain conditions and/or additional nested condition groups. Below is an example of a policy starting out with three condition groups. In this case, you can think of an implied OR operator between each of the red box condition groups. 

Nested Condition Groups

Nested condition groups exist in a hierarchy which can go four layers deep, each with their own operator, as shown here. This allows you to express complex decision-making processes clearly and efficiently.

Advanced Alert Policies

By using nested condition groups, NMS policy creators can now tune their alerts and notifications to only grab focus from network operators when doing so brings them critical network awareness.

Feature Requests & Bugs

This is a new feature and we're actively seeking your feedback and ideas to make it better. Reach out through your customer success rep or directly to the Kentik NMS Product Manager (Jason Carrier, jcarrier@kentik.com) if you'd like to influence our future development.