Opening Problem Statement

Meet Sarah, a network operations engineer responsible for managing several Cisco Meraki networks across multiple client organizations. Every day, Sarah spends hours manually checking network latency and packet loss statistics to identify problematic network sites that could impact end-user experience. The process is tedious, error-prone, and often leads to delayed responses when networks degrade, costing the company time and money and frustrating clients.

Imagine Sarah manually parsing Meraki dashboards or spreadsheets every 5 minutes during business hours, risking missed alerts or repeated alerts for the same network issues. The frequent manual work not only wastes Sarah’s time but also creates the risk that serious performance issues can go unnoticed until clients start complaining.

What This Automation Does

This n8n workflow solves Sarah’s problem by automating the monitoring of Cisco Meraki network uplink latency and packet loss across all organizations her account has access to. It runs every 5 minutes during business hours (Monday to Friday, 8 AM to 5 PM) and performs the following key actions:

Fetches all Meraki organizations linked to the API key.
Retrieves all networks for each organization.
Pulls five minutes of uplink latency and packet loss data for each network.
Calculates average latency and packet loss over the last five time stamps.
Filters out networks exceeding thresholds of 300ms latency or 2% packet loss.
Checks if an alert for the problematic network already exists in a Redis cache to avoid duplicate notifications.
Sends a formatted alert message with network details to a Microsoft Teams channel if no current alert exists.
Logs the alert in Redis with a three-hour expiration to prevent repeated alerts in that window.

By automating these tasks, Sarah gains reliable, timely insights into network issues and significantly reduces manual workload and alert fatigue.

Prerequisites ⚙️

n8n account to build and run the workflow.
Valid Cisco Meraki API key for accessing organization, network, and uplink data.
Redis instance configured to track active alerts.
Microsoft Teams account with a channel set up for receiving alert messages.
Credentials setup within n8n for HTTP Header Authentication (Meraki API), Redis, and Microsoft Teams nodes.

Step-by-Step Guide

1. Start with the Schedule Trigger Node

Navigate to the n8n editor and drag in the Schedule Trigger node. Set it to run every 5 minutes between 8 AM and 5 PM, Monday through Friday, using a cron expression: */5 8-16 * * 1-5. This ensures the workflow runs frequently only during working hours.

Outcome: The workflow will wake up regularly according to schedule.

2. Use HTTP Request to Get Meraki Organizations

Add an HTTP Request node named Get Meraki Organizations. Configure the URL as https://api.meraki.com/api/v1/organizations. Set Method to GET. Under headers, add Authorization (your API key via HTTP Header Auth credentials) and Accept with value application/json.

Outcome: You receive a list of all Meraki organizations the API key has access to.

3. Extract Organization Names and IDs with Set Node

Add a Set node named Get Org Name & ID. Map the fields CompanyName = {{$json.name}} and OrgID = {{$json.id}} to create simpler access to organization metadata.

Common mistake: Ensure the JSON paths are correct to avoid empty fields.

4. Retrieve All Network IDs per Organization

Add another HTTP Request node Get Network IDs. Use an expression for URL: https://api.meraki.com/api/v1/organizations/{{ $json.OrgID }}/networks. This dynamically pulls networks belonging to each organization.

Outcome: You get detailed network info including network IDs and names for each org.

5. Set Network Variables

Add a Set node Sets Network Variables. Map NetworkID = {{$json.id}}, NetworkName = {{$json.name}}, and networkURL = {{$json.url}}. This organizes the network data for easier manipulation later.

6. Fetch Uplink Latency and Loss

Add an HTTP Request node Get Uplink Loss and Latency. The URL is https://api.meraki.com/api/v1/organizations/{{ $json.id }}/devices/uplinksLossAndLatency?timespan=300. This fetches uplink stats for the last 5 minutes per organization.

7. Merge Network Info with Latency Data

Add a Merge node Combine latency to its respective Network. Configure it to join datasets using the fields NetworkID (networks) and networkId (latency data), enriching the network data with latency and loss stats.

8. Format Latency and Loss for Filtering

Add a Set node Makes Latency and Loss Filterable. Extract the last 5 time series entries’ latency and loss into individual variables TS0-Loss through TS4-Loss and TS0-Latency through TS4-Latency.

9. Calculate Averages with JavaScript Code Node

Add a Code node Average Latency & Loss over 5m with this JavaScript:

// Calculates average latency and loss over 5 samples
function calculateAverages(inputItems) {
  return inputItems.map(item => {
    const totalLoss =
      parseFloat(item.json['TS0-Loss']) +
      parseFloat(item.json['TS1-Loss']) +
      parseFloat(item.json['TS2-Loss']) +
      parseFloat(item.json['TS3-Loss']) +
      parseFloat(item.json['TS4-Loss']);
    const averageLoss = totalLoss / 5;
    item.json['AverageLoss'] = averageLoss;

    const totalLatency =
      parseFloat(item.json['TS0-Latency']) +
      parseFloat(item.json['TS1-Latency']) +
      parseFloat(item.json['TS2-Latency']) +
      parseFloat(item.json['TS3-Latency']) +
      parseFloat(item.json['TS4-Latency']);
    const averageLatency = totalLatency / 5;
    item.json['AverageLatency'] = averageLatency;

    return item;
  });
}

return calculateAverages($input.all());

Outcome: You get new fields AverageLoss and AverageLatency for each network.

10. Filter Problematic Sites with JavaScript Code Node

Add another Code node Filters Problematic sites with this code:

function filterItems(items) {
  return items.filter(item =>
    item.AverageLatency > 300 || item.AverageLoss > 2
  );
}

const inputItems = items.map(item => item.json);
const filteredItems = filterItems(inputItems);

return filteredItems.map(item => ({json: item}));

Explanation: Only networks with average latency above 300ms or loss above 2% pass through for alerting.

11. Check Redis to Avoid Duplicate Alerts

Add a Redis node Check if Alert Exists that queries using {{ $json.NetworkName }} as key. It checks if an alert is already logged for the network.

12. Transform Null Responses for Filtering

Add a Code node Create Response to convert Redis “null” results into a boolean alertExists property, to help in subsequent filtering.

13. Merge Alerts to Filter Already Alerted Networks

Add a Merge node Merge to join problematic sites with Redis results, keeping non-matching (new alerts) only.

14. Send Alert to Microsoft Teams

Add a Microsoft Teams node Message Techs to send a styled chat message to a designated channel. It includes network name as a clickable link, average latency, and loss.

15. Log the Alert in Redis

Finally, add a Redis node Log the Alert to record the alerted network with a TTL of 3 hours, so the same alert isn’t sent multiple times within that window.

Customizations ✏️

Modify Alert Thresholds: In the Filters Problematic sites code node, change 300ms latency or 2% loss thresholds to meet your organization’s sensitivity.
Change Alert Channel: In the Message Techs Microsoft Teams node, update chatId to notify a different team or channel.
Create Tickets Instead of Messages: Replace the Microsoft Teams node with a PSA system node (like ConnectWise Manage) to automatically create tickets for network issues instead of just sending messages.
Adjust Schedule: Modify the cron expression in the Schedule Trigger to change monitoring frequency or hours.
Add More Metrics: Extend the Makes Latency and Loss Filterable set node to pull more detailed uplink statistics if required.

Troubleshooting 🔧

Problem: HTTP Request node returns 401 Unauthorized

Cause: Invalid or missing Meraki API key in HTTP Header Auth credentials.

Solution: Go to Credentials in n8n, edit your HTTP Header Auth credentials, and ensure your API key is correct and active. Also, ensure the Authorization header is properly configured.

Problem: Redis node returns null unexpectedly

Cause: Key does not exist or Redis connection problem.

Solution: Verify Redis server uptime and connection settings in n8n. Ensure keys are correctly set and the Redis instance is reachable.

Problem: Alerts are sent repeatedly for the same network

Cause: Redis TTL may not be set properly or Redis node isn’t logging alerts.

Solution: Check the Log the Alert Redis node to confirm the TTL is set (10800 seconds). Confirm keys are stored without errors.

Pre-Production Checklist ✅

Have valid Meraki API credentials configured in n8n.
Test fetching organizations and networks via the HTTP Request nodes to confirm API connectivity.
Verify Redis connectivity and ability to set and get keys.
Test Microsoft Teams message sending with sample data.
Run workflow manually first to ensure data flows as expected.
Check logs for any errors or unexpected results.

Deployment Guide

Activate your workflow by enabling it in the n8n editor. Monitor execution logs regularly for failures.

Since it runs every 5 minutes, ensure your n8n instance is online and stable during working hours.

You can choose self-hosting options for n8n if you want full control (e.g., on Hostinger – buldrr.com/hostinger).

FAQs

Q: Can I use another messaging tool instead of Microsoft Teams?
A: Yes, nodes for Slack, email, or ticketing systems can replace Teams depending on your preferences.

Q: Does this workflow consume many API credits?
A: Since it’s polling every 5 minutes, consider your Meraki API rate limits to avoid hitting caps.

Q: Is my alert data safe?
A: Data is transmitted securely using header-authenticated HTTPS calls; ensure your Redis instance is secured as well.

Q: Can this handle multiple organizations and networks?
A: Yes, this workflow dynamically queries all organizations and networks available via the API key.

Conclusion

By following this guide, you have built an automated solution in n8n that continuously monitors Cisco Meraki networks for latency and packet loss issues and notifies your technical team only when necessary. This saves hours of manual checking each day, reduces overlooked network problems, and optimizes your team’s response time.

Consider extending this workflow to automatically create support tickets or add metrics like WAN jitter or throughput. With n8n’s flexibility and the power of Cisco Meraki APIs, you now have a robust foundation for managing network health efficiently.

Remember, the key is consistent, reliable monitoring coupled with timely alerts—something this workflow delivers perfectly.

Automate Cisco Meraki Network Latency Alerts with n8n