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.

If you work in network peering and interconnection, you probably remember when we first introduced the PeeringDB integration to Kentik Portal a few years ago. That integration gave network teams easy access to up-to-date information about an Autonomous System's (AS) network footprint, peering relationships, and interconnection opportunities, directly within Kentik.

Now, we're taking that integration a step further with Kentik AI Advisor.

AI Advisor can now incorporate PeeringDB's extensive interconnection data into its AI-powered investigations and analysis, bringing valuable peering intelligence directly into the investigative process.

Let's take a closer look at what's new and what it means for you. 

PeeringDB 101

For peering and interconnection teams, PeeringDB is an essential resource for understanding where networks operate, how they interconnect, and under what conditions they're willing to exchange traffic.

This community-maintained directory provides detailed information about registered Autonomous Systems (ASNs), including:

• Data center presence: The facilities where networks have a physical presence, helping teams identify opportunities for private network interconnects (PNIs).
• Internet Exchange (IX) participation: The exchanges where networks are present, including their peering IP addresses, enabling teams to identify public peering opportunities and establish BGP sessions.
• Peering policies: The requirements and conditions under which networks are willing to establish interconnection relationships.

These insights inform a wide range of strategic and operational decisions, from evaluating inbound peering requests and identifying potential PNI partners to selecting the best Internet Exchanges for localized traffic exchange. They also help teams identify shared facilities for interconnection, minimize unnecessary backhaul costs, and determine where transit providers can efficiently deliver connectivity to prospective customers.

But PeeringDB is only one piece of the interconnection puzzle.

Developing an effective peering strategy also requires understanding what's actually happening across your network. That means analyzing traffic volumes, source and destination ASNs, traffic paths, and the types of connectivity carrying that traffic, whether public peering, private interconnection, or IP transit.

Equally important is understanding your network's current state. Do you already have BGP peering sessions established with a potential partner? Which routers and interfaces are involved? These answers often require consulting monitoring systems, routing data, and device configurations alongside PeeringDB.

Traditionally, bringing these data sets together has required network teams to move between multiple tools, manually correlate information, and piece together the insights needed to make informed interconnection decisions.

That's where Kentik AI Advisor changes the equation.

Kentik brings together the critical data needed to inform peering and interconnection strategies, and AI Advisor can now put that information to work:

1. Unified access to critical network intelligence: Kentik combines PeeringDB interconnection data, traffic telemetry enriched with connectivity classifications, and router configuration context.
2. AI-powered, cross-domain investigations: AI Advisor can reason across these data sources, connecting interconnection opportunities with actual traffic behavior and network configuration.
3. Investigations tailored to your network: With Custom Network Context (aka AI Advisor's claude.md) and AI Runbooks (aka AI Advisor's Claude Skills) teams can guide AI Advisor using their network-specific knowledge, operational practices, and established investigation workflows.

Here's the great news moving forward: 

1. Kentik collects all of this information: PeeringDB, Connectivity Type-enriched Traffic telemetry, Router Configuration
2. Kentik's AI Advisor has access to it and can reason with it
3. You can mix and match reasoning across these datasets using the guided context you have provided in both Custom Network Context (aka AI Advisor's claude.md) and AI Runbooks (aka AI Advisor's Claude Skills)

The net result is now AI Advisor can tackle complex, multi-layer peering and interconnection questions that previously required significant manual investigation, helping network teams evaluate opportunities, optimize connectivity decisions, and turn network intelligence into action.

Let's explore how you can put AI Advisor to work as an AI-powered teammate for peering and interconnection management.

The Basics: PeeringDB Intelligence in AI Advisor

AI Advisor can now automatically tap into PeeringDB's extensive interconnection data as part of its investigations. Using context-aware triggers, AI Advisor invokes a dedicated PeeringDB sub-agent when relevant, accessing detailed information about Autonomous Systems (ASNs), Internet Exchanges (IXes), and data center facilities. It can retrieve and analyze this information independently or combine it with other data sources and tools through multi-step investigations.

Here's a look at some of what AI Advisor can do with PeeringDB data:

• Identify shared interconnection opportunities: Find Internet Exchanges and data center facilities where any two or more ASNs have a common presence, or explore the complete IX and facility footprint of any individual ASN.
• Discover and compare Internet Exchanges: Identify IXes in a specific city, region, or country and compare them based on attributes such as member count, open peering policies, and aggregate member port capacity. AI Advisor can also locate IXes and facilities within a specified geographic radius.
• Explore network presence and peering policies: Identify which ASNs are present at a particular IX or facility, filtering by criteria such as peering policy, contractual requirements, and available peering IP addresses.
• Retrieve peering connection details: Look up an ASN's ports and IP addresses at specific Internet Exchanges to support interconnection planning.
• Access peering policies and contacts: Retrieve relevant NOC and peering contact information, traffic ratio requirements, peering policy URLs, and other published interconnection requirements.

And that's just a starting point. Whenever AI Advisor invokes the PeeringDB sub-agent, users can inspect the underlying tool calls and retrieved data through the View Details side panel, providing transparency into the information used to inform its analysis.

These capabilities are valuable even for standalone queries. Rather than switching between Kentik Portal and PeeringDB to look up network footprints, peering policies, or interconnection details, users can access that information directly through AI Advisor, keeping their investigations in one place. 

In the next sections, we'll look at combining this data with other datasets in AI Advisor to demonstrate power user use cases!

Putting AI Advisor to Work: Advanced Peering and Interconnection Use Cases

Accessing PeeringDB data through AI Advisor is valuable on its own, but the real power comes from combining that intelligence with Kentik's broader network telemetry, device configurations, and operational context.

Let's explore how AI Advisor can bring these data sources together to streamline complex peering investigations, identify interconnection opportunities, and support more informed peering decisions.

Understand Existing BGP Peering Sessions

Before evaluating new interconnection opportunities, it's important to understand the peering relationships already established across your network. For devices monitored by Kentik NMS, AI Advisor can retrieve information about existing BGP sessions to help determine whether you're already peering with a particular ASN and understand the current state of those relationships. Similar information can also be obtained through router configurations when devices are enrolled in Kentik's Config Backup capability, or by executing show commands directly on supported devices with Command Access enabled.

Combine Traffic Intelligence with PeeringDB Data

Kentik regularly synchronizes PeeringDB data, including the IP address ranges associated with Internet Exchanges. This information helps enrich customer flow telemetry with additional interconnection context, making it easier to analyze traffic based on source and destination ASNs and connectivity attributes.

Consider a common peering optimization scenario: How much IP transit traffic could you potentially shift to direct interconnection if your network established a presence at Equinix Ashburn?

With Kentik Data Explorer, experienced users can investigate this opportunity by applying filters to identify traffic currently traversing transit links that may be eligible for alternative interconnection.

But what if you don't know which filters to apply or aren't familiar with Data Explorer? Simply ask AI Advisor.

AI Advisor can bring together traffic analysis and PeeringDB intelligence to help identify potential interconnection opportunities without requiring users to manually construct the underlying queries.

Fast forward: towards an AI-powered Peering Manager

Identifying potential transit offload is only the first step. A peering manager also needs to determine which networks to approach, where interconnection makes sense, and what information is needed to initiate a peering relationship.

Continuing our Equinix Ashburn example, AI Advisor can help translate the analysis into an actionable plan, identifying prospective peering partners and providing the relevant interconnection details needed to pursue those opportunities.

This helps bridge the gap between identifying an optimization opportunity and taking the next steps toward implementing it.

Streamline Peering Request Evaluations with AI Runbooks

Now consider another routine responsibility for peering managers: evaluating inbound peering requests. When another network requests a peering relationship, the evaluation typically involves several steps:

1. Analyze traffic: Examine traffic volumes and patterns exchanged with the requesting ASN, including inbound and outbound traffic ratios.
2. Evaluate interconnection options: Review the requesting network's PeeringDB footprint to identify shared Internet Exchanges or data center facilities.
3. Apply peering policies: Assess whether the request meets established requirements, such as minimum traffic thresholds, traffic ratios, and geographic criteria.
4. Determine eligibility: Evaluate the findings against your organization's peering policies to determine whether the request should be approved.
5. Prepare next steps: Document the decision and outline the actions required to establish a BGP peering session at an agreed-upon location.

Traditionally, this process requires peering managers to move between multiple tools, manually correlate data, and apply internal policies before reaching a decision.

With AI Advisor and AI Runbooks, much of that multi-step evaluation process can be automated.

AI Runbooks allow network teams to define repeatable investigation workflows using natural-language instructions, giving AI Advisor a structured process to follow when evaluating peering requests.

For a deeper introduction to this capability, check out our recent webinar, Transforming Network Operations with AI Advisor. To get started, simply define the steps of your peering evaluation process in an AI Runbook.

Here's an example of a basic Peering Evaluation Runbook. While it can be expanded and customized to reflect more sophisticated policies, it demonstrates how AI Advisor can orchestrate an investigation across multiple data sources.

In this example, the Runbook instructs AI Advisor to first query Kentik Data Explorer to analyze the requesting ASN's traffic profile over the past seven days. It then evaluates common Internet Exchange and facility presence using PeeringDB data and checks the findings against predefined peering requirements, including minimum traffic thresholds.

Rather than requiring a peering manager to execute each step independently, AI Advisor follows the defined workflow to build a cohesive, evidence-based evaluation.

AI Advisor can also dynamically invoke the appropriate Runbook based on the context of a user's prompt, making it possible to initiate the process with a simple natural-language request. When a Runbook is invoked, AI Advisor indicates that it's following the defined workflow, providing visibility into the steps guiding its investigation.

Build Your Own AI-Powered Peering Workflows

The peering request evaluation example is just one of many ways to put AI Advisor and AI Runbooks to work. By defining repeatable procedures tailored to your network, peering policies, and operational priorities, you can equip AI Advisor to tackle a wide range of interconnection planning and optimization tasks.

Here are two more examples of what's possible:

Optimize Interconnection to Reduce Transit Costs and Improve Performance

Create an AI Runbook that evaluates interconnection opportunities in a specific country or region to identify ways to reduce IP transit costs, localize traffic exchange, and improve network performance. For example, the Runbook could instruct AI Advisor to:

• Analyze traffic to and from ASNs in the target geography.
• Identify Internet Exchanges with the greatest overlap among those networks.
• Evaluate potential data center locations based on network presence and interconnection opportunities.
• Recommend strategic locations for expanding your network's interconnection footprint.

Audit Existing Peering Relationships to Identify Optimization Opportunities

Not all optimization opportunities require establishing new peering relationships. Sometimes, you may already have a peering session with a network but still exchange a portion of your traffic with that ASN over paid transit. An AI Runbook could help uncover these inefficiencies by:

• Identifying top inbound and outbound ASNs reached through existing IX or PNI peering connections.
• Analyzing the distribution of traffic exchanged with those ASNs across transit, public peering, and private interconnection.
• Flagging networks where traffic continues to traverse transit despite an existing peering relationship.
• Investigating the relevant prefixes and routing behavior to identify potential opportunities to shift traffic onto established peering connections.
• Generating a documented report of findings that can be shared with peering partners to support further investigation and optimization.

These are just a few examples of how AI Advisor can help turn complex, multi-step peering investigations into repeatable, AI-powered workflows.

Now it's your turn.

Whether you're evaluating new peering partners, optimizing interconnection costs, or auditing existing relationships, AI Advisor gives you the tools to build workflows around your network's unique requirements.

What will you build with your AI-powered peering teammate?

As you already know, there are two ways to interact with AI Advisor: Co-Pilot Mode where AI Advisor is docked to the current screen you are on (and has page context in memory), and the Full Screen Mode which, well... kind of speaks for itself.

Today we're giving the Full Screen Mode a bit of a facelift, so read on!

The new AI Advisor sidebar

One of the piece of feedback we've gotten is that the AI Settings that host important operational aspects to how AI Advisor operates are burried. Unlike say, collection configurations, AI Advisor settings (notably Runbooks and Custom Network Context) are meant to be living reflections of the operational reality of your network. 

They by definition are better when you create/update them as you go. Forcing users to dig into settings and break the flow from AI Advisor was bad user experience. We're changing that to make AI Advisor settings easier to access, something that compounds with the recently announced RBAC for AI Advisor. 

Here's how in a screenshot since a picture is always better than a thousand words:

The main new change is the sidebar that

• is horizontally resizable
• is collapsible (so you can take the full screen for your chat session)
• that now gives direct access to AI Settings: you don't need to go through Company Settings > Kentik AI to access these settings anymore

Note: The "Recent" section of the sidebar panel is a carryover from the previous version, it lets you navigate existing sessions and load them in one click in the central panel. Pinned Chat sessions will always appear at the top of the "Recent" section of the side panel - this section 

New AI Chat Sessions History screen

When clicking on the history button, a full screen history will load into the main panel. If you do this in the middle of a AI Chat Session, you can always go back by selecting the session from the "Recent" section.

This AI Chat History screen presents a few benefits

• presents itself in a full screen experience instead of being locked in a side bar
• allows users to easily filter between their own AI Chat Sessions, that of their company, or those automatically-generated by other parts of Kentik Portal  (as with the AI Auto-Investigation feature to come)

What do you think ?

We like to share these minor, quality-of-life improvements with our users, and we'd love to know what your thoughts are on this new version.

- Are you Team Co-Pilot Mode or Team Full-Screen Mode ?
- Do you think this new UI is better based on how you use AI Advisor ?
- What other improvements would you like to see us bring to our AI Advisor User Experience ?

When we originally added Syslog and Traps collection capabilities for Kentik-registered Devices, one thing was cruelly missing: while we offered a tab on the Device Details screen for Syslog from the get-go, the same for SNMP Traps was absent.

With this release we're correcting that mistake to make it easier to see specifically what Traps have been triggered on a given device! 

New Infrastructure > Device filters

First-off, you want to be able to find Devices with SNMP Traps enabled and activity in the Infrastructure > Devices screen.
This new filter is located in the NMS Status > SNMP Traps section of the left-side filtering panel - see screenshot below

Visualizing SNMP Traps

When clicking on a device with SNMP Traps, you'll now see an additional tab showing up. As you can see, it has been built with the exact same familiar UI as the Syslog tab.

You can also select the type of traps you want displayed with the Trap Type filter, or type a search pattern in the upper search bar to filter the records within the time range.

Both the Parsed PDUs and Parsed KVs in each row can be inspected in a more human legible format when clicking on the double arrow icon in the cell

What's next ?

First off, remember that both Syslogs and SNMP Traps are first class citizens in Data Explorer - they are labelled as "Events". This means that you can already slice and dice syslogs as well as SNMP Traps to further troubleshoot event that could span over your entire fleet of devices. They are also a key source of telemetry that AI Advisor can access when doing the same too!

In the near future, we'll be releasing a major overhaul of Data Explorer, Metrics Explorer and Dashboards, merging all three in a single analytics and dashboarding app that will allow the following:

• a single Analytics App that allows you to query Traffic (Flow) data, NMS (Metric, state...) data and Synthetics data in a central place
• a drastically revised dashboarding experience allowing our users to build dashboards that mix and match analytics from the three aforementioned datasets, but also simple yet powerful extensions to the Guided Mode capability currently present in Dashboards

So stay tuned as the convergence between Flow, NMS and Synthetics products gets tighter and more powerful in the year to come! 

In the mean time, do let us know what next evolutions of each of these products you'd like to see!

In previous posts, we've discussed how AI Advisor Runbooks help teams capture the operational expertise, knowledge, and procedures specific to their networks, enabling AI Advisor to more accurately investigate issues and guide teams toward answers.

Until now, Runbook management was tied to Kentik's legacy user levels, meaning only Admins and SuperAdmins could create and maintain Runbooks. This created an unnecessary barrier to adoption for a very useful feature as the people who know your network best or operate it most hands-on aren't necessarily the administrators of the tool. 

That changes today. With role-based access control (RBAC) for AI Runbooks, organizations can give more team members the ability to contribute their expertise without granting them broader administrative privileges.

But expanding access also requires maintaining control over how Runbooks are managed. Because Runbooks influence how AI Advisor investigates issues and responds to questions, changes to their content can affect the answers users receive. It's important that those changes are authorized, transparent, and auditable so users can trust the knowledge guiding AI Advisor's behavior.

This reflects a broader principle behind our approach to AI: trust is essential to adoption. Organizations need the flexibility to put AI capabilities in the hands of more people while maintaining appropriate governance over the knowledge and instructions those capabilities rely on.

RBAC builds on the safeguards and we're rolling it out to AI Runbooks now, and to Custom Network Context in the near future.
In a nutshell, we are conducting Trus/Safety work around the entire AI stack:

• Visibility into changes, even for users without permission to modify these configurations.
• Version history and rollback, allowing teams to track changes and restore previous versions.
• Audit logging for Create, Edit, and Delete actions, providing accountability for changes.

Together, these capabilities make it possible to expand participation in building AI Advisor's operational knowledge while retaining oversight and control.

RBAC for Runbooks

If you go to Company Settings > RBAC Management you will notice that Roles now include a new category of permissions titled Kentik AI

Depending on your Runbook permissions, the Settings > Kentik AI left-side panel may have the Runbooks entry disabled: the screenshot below illustrates what it looks like when a user has all Runbook permissions disabled.  

The Settings > Kentik AI > Runbooks screen will offer different functionality depending on a user's RBAC permissions, as displayed in the screenshots below.

Example of the Runbook screen for a user with CREATE, EDIT and DELETE RBAC permissions

Example of the Runbook screen for a user with VIEW only RBAC permissions

Coming up next ?

As you have noticed, we're continuously adding AI Safeties around AI Advisor. Next on our list we'll be adding the following:

• RBAC permissioning for Custom Network Context
• RBAC permissioning for AI Advisor Chat Sessions: this will eventually regulate what AI Chat sessions users have access to (all users currently have access to all sessions)

Let us know what you think!

Getting network data into Grafana shouldn't stop at the dashboard. We understand how frustrating it can be to build a great Kentik view and then have no way to alert on it, or to watch a panel-heavy dashboard crawl while it waits on API calls. That's why we're thrilled to announce v3.0 of the Kentik plugin for Grafana. We rebuilt it as a backend datasource, so your Kentik data works with Grafana the way the rest of your data does.

Some key features: 

• Alert on your network data: Queries now run on the Grafana server, so Kentik flow and NMS metrics work with Grafana Alerting, recorded queries, and shared dashboards.
• Load heavy dashboards without hammering the API: Duplicate panel queries are coalesced into one call, and rate-limited requests retry automatically.
• Start from seven ready-made dashboards: Traffic, Top Talkers, a global traffic map, geo flow, and NMS device health import in one click.
• Build dashboards that adapt: Template variables can now drive the measurement, metrics, dimensions, and filter values of a query.

What's New?

A backend datasource

Query execution, result parsing, credential handling, and the dictionary cache now run server-side in a Go backend instead of the browser. This is what makes alerting, recorded queries, and shared dashboards possible. Queries now run against Kentik's newer query API, and every request identifies itself as kentik-grafana-plugin/.

Fewer API calls, fewer timeouts

v2.0 batched panel queries in the browser. v3.0 handles this on the server:

• Identical queries issued at the same time, or within 30 seconds of each other, share one upstream call.
• Up to 10 queries in a request run in parallel.
• HTTP 429 and 502 responses retry with exponential backoff and honor Retry-After.

A rebuilt query editor

• Measurement picker: Browse Kentik measurements grouped by family (Traffic, NMS, NMS Interfaces, and more) with search and full keyboard navigation. The dimension picker warns you when a metric and dimension come from different namespaces.
• Familiar controls: Limit (Top N), filters, Merge Series Function, and Alias By / Prefix with autocomplete are all still here.
• Response format: Return time series, a table (one row per series, ideal for Geomap, bar gauge, and table panels), or a node graph (nodes and edges for Grafana's Node Graph panel).
• Clearer errors: If a metric and dimension can't be combined, the error names the conflict and suggests the universal equivalent.

Seven bundled dashboards

Import them from the Dashboards tab on the datasource configuration page.

Smarter dashboard variables

Variables can drive measurement, metrics, dimensions, rollups, and filter values. A new values(, ) function builds live variables, such as a device picker that always reflects what Kentik is receiving.

Open in Kentik, from every series

Each series carries an Open in Kentik link that opens Data Explorer in the right region (US, EU, or custom). It also carries dimension values as field labels, so map lookups and transforms work.

Grafana 13 supported

In the v2.0 post we flagged a credential-save error on Grafana 13. v3.0 is tested against Grafana 11.6, 12.4, and 13.0.

Why It Matters

• One place to watch and act: Alert rules, dashboards, and on-call routing can use the same Kentik data your team already trusts.
• Dashboards that scale: Panel-heavy dashboards and many viewers no longer mean one API call per panel per person.
• Faster time to first dashboard: NMS health, flow, and geography views come ready to import instead of being built from scratch.

What's Changing

• Minimum Grafana version is 11.6.
• Your existing panels keep working. Panels saved with v2.0 queries are translated automatically and show a deprecation notice. Re-save them in the new format, because this compatibility layer will be removed in a future release. A translated panel currently opens with blank editor fields, so plan to reconfigure it when you re-save.
• Open in Kentik opens Data Explorer, not your exact query. In v2.0 the link carried your query, time range, and filters. In v3.0 it lands on the Data Explorer for your region and you re-enter the query. We're working on restoring the full deep link.
• Network Health (OSI) is now Traffic Detail. The bundled dashboards were rebuilt for the new query model.
• Events data isn't available yet. Syslog, SNMP traps, and other /events measurements can't be queried through the new API today.
• Check your outbound access. The Grafana server calls the Kentik API directly. If you restrict egress, allow grpc.api.kentik.com (US) or grpc.api.kentik.eu (EU).

Get Started!

Already on v2.x? Update from the Grafana plugin catalog, or run grafana cli plugins update kentik-connect-datasource. Then open Connections > Data Sources > Kentik, click Save & test, import the new dashboards from the Dashboards tab, and re-save your existing panels in the new format.

New to the plugin? In Grafana, go to Connections > Add new connection, search for "Kentik", and install kentik-connect-datasource. Enter your region, email, and API token, then import the bundled dashboards.

Still on the legacy kentik-connect-app (v1.x)? Follow the migration guide, then update to v3.0.

Ready to alert on your network? Grab v3.0 from the Grafana plugin catalog, and see the Kentik Knowledge Base for setup details.

Up until today, our users could only Authenticate our AI Advisor MCP into their own agentic solutions using an API Key and Token. A large number of users asked if we could add OAuth to the MCP Authentication methods, so today's post is about just that!

There are multiple benefits to using OAuth to Authenticate against AI Advisor's MCP:

• OAuth allows our customers to control access to the MCP directly from their IdP (provided said users have a Kentik Portal account): centralized auth management
• OAuth is useful for integrations: instead of relying on the API Token of a single user to build an integration and therefore making it brittle, OAuth elegantly solves for this use case, allowing more easy management for the business
• OAuth prevents security issues such as a User's Kentik API Token leaking or being intercepted
• More generally, OAuth has become the choice standard for MCP Authentication industry wide

Let's dive in!

Adding AI Advisor MCP to Claude Code

Before lauching Claude Code, punch this command in your project directory: 

claude mcp add ai-advisor --transport http https://api.kentik.com/mcp 
(use api.kentik.eu if you are on an EU account)

Then launch Claude Code and fire an /mcp command, you'll see the ai-advisor MCP configured, but unauthenticated, and follow the steps - a browser tab will be invoked to login to Kentik Portal.
The series of screenshot below illustrates these steps.

When done, the /mcp command should give you a similar output with a green check indicating that AI Advisor MCP is connected!

Adding AI Advisor MCP to Claude Desktop

Use the [+] button in your prompt box in Claude Desktop and select Add Connector > Add custom connector

Use this MCP URL to configure the custom connector: https://api.kentik.com/mcp (or api.kentik.eu if you're on an EU account) and follow the step by step, which will invoke a Kentik Portal login page.

Follow the steps until a browser tab opens prompting you to Authenticate

You're done once the browser tab gets to this state

Adding AI Advisor MCP to Cursor

 While in Cursor, use the [+] button in your prompt box, and select MCP > Manage, and on the next screen select New MCP Server, it will open your ~/.cursor/mcp.json config file, updated it as detailed in the screenshot below using this config block. (user api.kentik.eu if you are an EU customer) and Save the mcp.json file.

{  "mcpServers": {    "Kentik AI Advisor MCP": {
      "url": "https://api.kentik.com/mcp"
    }
  }
}

Then click on the Authenticate option for the MCP server entry you just created

and follow the instructions in the resulting browser page until the MCP server is displayed as below

The AI team over at Kentik is very excited to see what your teams are going to build using our MCP, give us a shout if you want to demo your integrations and we'll hop on a call!

This feature request is a small-ish one, but you'd be surprised how many users have been asking for it in recent times :)
Title says it all, our users love AI Advisor so much that they want to make it their landing page, so here it is !

How can I switch my landing page to AI Advisor ?

First head out to your user profile, on the upper right corner of Kentik Portal

Once there, find the Landing Page setting as shown below

And you're done ! 

Hint: you can always go back to your landing page by clicking the upper left Kentik Logo 

What more can I do ?

Bulk-setting the landing page for multiple users in one go

If you go to the Settings > Users you'll notice you can select multiple users, it will make a bulk edit floater open at the bottom of the screen.
If you are an Admin user, you'll then be able to modify a variety of user attributes in bulk.

Role-Sets & the Landing Page

If you are an avid RBAC (Role Based Access Control) admin user, you may already have assigned users to Role-Sets: these objects are groups of RBAC Roles that can be assigned to users.
One of the things Role-Sets also allow you to do is let you configure a single Landing Page. Every user under this Role-Set will have their landing page follow this configuration.
We have made sure to add AI Advisor to the configuration options of these Role-Sets.

Static IPs Are Here for Global Agents!

We are thrilled to announce that Static IP support is officially live for Kentik Synthetics Global Agents!

Managing network access, firewalls, and allowlists just got a whole lot easier. If your testing relies on fixed source IPs to get past strict firewall rules or internal access control lists (ACLs), this update is designed specifically for you.

What’s New?

• Filter by Static IP: Effortlessly search and filter the Global Agents list to isolate agents configured with static IP addresses.

• Agent Details View: Instantly view assigned static IP addresses directly within the Agent Details panel for fast verification and allowlist configuration.

• Streamlined Test Creation: Select agents with confidence! You can now filter for static IP agents directly within the Test Creation workflow, ensuring your synthetic tests run smoothly through locked-down gateways.

Why You’ll Love It

No more guessing which agent IP to put on your allowlist or dealing with broken test runs due to unexpected IP shifts. With static IPs, you gain predictable source addresses, simplified perimeter security management, and seamless testing against protected endpoints and private services.

In a follow up release, you will be able to retrieve the list of global agent static IPs via the API.

Ready to streamline your agent management? Head over to Synthetics > Agents to check out the new filters today!

A steady portion of our Kentik AI Advisor work happens behind the scenes which main goal is to make it both safer and more transparent for users to feel confident when they use it.
When it comes to AI, we strongly believe that security, safety and transparency are key features, even though they're never listed as such and hardens the trust that our users place in Kentik, as well as provide the sound guardrails required for adoption to keep growing.

Today's release is about another one of these focused runs, it is about our engineering team adding guardrails around AI Advisor's Custom Network Context - read on!

AI is Magic. Sometimes too much.

As detailed in this previous post about Kentik's AI Runbooks, both the Custom Network Context (aka CNC) and Runbooks deeply affect AI Advisor's reasoning.
Imagine Kentik users whose workflow could rely on a very specific prompt, which they'd for example routinely enter every morning with their first coffee - say What's the status of my edge routers this morning ?

In this example, imagine that the list of Edge Routers is documented in their company's Custom Network Context. (which is one of the most common usages of CNC, by the way...)
Also a reasonable hypothesis: users who rely on this mapping ignore that it has been configured via CNC by a benevolent coworker.

What the above implies is the following sum of safety features:

• provide ways to track any AI related configuration change (in this case Custom Network Context)
• allow users to determine who made the change and when
• allow the security team to be able to research modifications on such configuration objects, even if they are not users of AI capabilities
• allow users to rollback such changes if it turns out that their effect on AI Advisor answers negatively impacts its answers

This is what today's feature is all about !

Side note: versioning and audit logging was already available for Runbooks, we extended them and perfected them for CNC.

Updated Custom Network Context Interface

Let's head to Company Settings > Kentik AI > Custom Network Context.
First off, we gave the default empty state a bit of a facelift, you know - while at it...

For those out there with an already populated Custom Network Context, here's what it looks like now: a right-side drawer contains every previous version with:

• Date, Author and Summary metadata attached to it
• The ability to load it in the main center section, from where the user will be able to
  • Inspect the Diff with the previous version
  • Trigger a Roll back to said version

Selecting a previous version, and then switching to Diff display mode:

Custom Network Context & Audit Log

While working on AI Safety measures for Custom Network Context, we also added support for Audit Log: with any modification on the CNC (Create, Edit, Delete), an Audit Log line is now generated, and visible in the usual Company Settings > Audit Log as displayed in the screenshot below.