DEV Community: Tony Metzidis

How to Finally (and Iteratively) Kill Every Last 'npm audit'

Tony Metzidis — Thu, 02 Apr 2026 19:24:53 +0000

Let’s be honest: npm audit is a necessary evil. If you manage a monorepo, a large scale-backend microservice architecture, or even just have fifty toy projects in your /dev folder, you know the dread. You run an audit, get 400 vulnerabilities, and standard npm audit fix just breaks things.

The real problem isn't fixing the vulnerability; the problem is the management of the vulnerabilities.

Manually cd-ing into 30 different directories, running the audit, deciphering the output, deciding which package.json to edit, and then doing the work? That's an efficient way to burn out an afternoon.

Here is the tool you didn’t know you needed.

The Problem: Multi-Directory Triage

You are working across multiple contexts (multiple directories). You have dozens of tasks:

Find the package.json.
Navigate to that folder.
Run the audit.
Decide if it’s a manual fix (Mocha 11x, looking at you) or an audit fix --force candidate.
Mark it done and move on.

The standard Unix toolbox doesn’t have a built-in interactive "loop through directories and run commands, pausing for input" command.

The Solution: `fzf` as an Interactive Runner

/home/tonymet/dev/
> api-gateway-service                                                  │ Path: ./api-gateway-service
  auth-provider                                                       │ 
  legacy-reporting-tool                                               │ 🔒 npm audit report
  frontend-dashboard                                                  │ 
  shared-auth-library                                                 │ 📉 Low             1
                                                                      │ 📈 High            3
                                                                      │ 💥 Critical        1
                                                                      │ 
                                                                      │ Found 5 vulnerabilities in 890 scanned packages.
                                                                      │ 3 vulnerabilities require manual review.
                                                                      │ 
                                                                      │ Run `npm audit fix` to fix 2 of them.
                                                                      │ 
                                                                      │ =========================================================
                                                                      │ Critical: Remote Code Execution
                                                                      │ Package: serialize-javascript
                                                                      │ Dependency of: mocha [dev]
                                                                      │ Path: mocha > serialize-javascript
                                                                      │ More info: https://github.com/advisories/GHSA-hxcc-f52p
                                                                      │ 
                                                                      │ =========================================================
                                                                      │ High: Prototype Pollution
                                                                      │ ... (rest of audit output scrolled)
[5/5] -----------------------------------------------------------------│
> _

The solution is combining the powerhouse finder fzf with some standard find commands.

We are going to use fzf not just to select a file, but as an interactive dashboard.

The One Command to Rule Them All

Here is the command (Unix/Linux/macOS):

find . -name "package.json" -not -path "*/node_modules/*" \
| fzf --preview 'echo $(dirname {}) && cd $(dirname {}) && npm audit' \
      --preview-window=right:80%

What is happening here?

This looks complicated, but it's remarkably elegant:

find . -name "package.json" -not -path "*/node_modules/*": This is our discovery engine. It searches the entire directory tree (.) for package.json files, but critically skips anything inside a node_modules folder (we don’t want to audit dependencies' dependencies, only the root projects). This feeds a clean list of file paths to the next command.
| fzf: We pipe that list into fzf, the interactive finder. This creates the interface.
--preview '...': This is the magic. When you highlight a path in fzf, this entire script runs in the side-pane:
- echo $(dirname {}): Shows you the clean path to the directory containing the package.json.
- cd $(dirname {}): Temporarily navigates the preview process into that directory.
- npm audit: Executes the audit specifically inside that folder.
--preview-window=right:80%: We give the preview window 80% of the screen. Why? Because npm audit output is verbose, and you need to be able to read the specifics of the dependency tree to make triage decisions.

How to Use the Interface

When you run this command, your terminal transforms:

Left Side: A list of every project in your /dev folder that has a package.json.
Right Side: The live output of npm audit for whichever project you highlight.

Now you can triage! Use the up and down arrow keys to quickly review the security status of every project without leaving the dashboard.

Actually "Doing Work"

The standard configuration above is a read-only view. It lets you quickly see where the major problems are (e.g., "Oh, all these old 2022 projects need Mocha 12").

If you want to actually execute fixes from within the interface, we need to bind a key:

find . -name "package.json" -not -path "*/node_modules/*" \
| fzf --preview 'echo $(dirname {}) && cd $(dirname {}) && cat package.json' \
      --preview-window=right:80% \
      --bind 'enter:execute(cd $(dirname {}) && npm audit fix && echo -n DONE | read)+down'

What this version does:

Default Preview: Shows package.json (running audit constantly in preview can be slow).
Enter (Binding): When you hit Enter:
1. It runs npm audit fix in that folder.
2. It uses echo -n DONE | read to pause the interface (pressing any key resumes).
3. +down: After you resume, it automatically moves the selection to the next directory on the list.

It mimics the exact "triage and advance" workflow of an interactive rebase.

When the interface is painless, you are more likely to run it. When the effort of auditing 100 directories is reduced to "holding down the down arrow," security gets addressed.

Stop Paying the "Security Tax": Reclaiming 30% Performance in WSL 2 on Windows 11

Tony Metzidis — Wed, 25 Mar 2026 05:51:27 +0000

If you develop in WSL 2, you are likely sacrificing nearly a third of your CPU performance to kernel-level security mitigations. In a recent deep dive, I benchmarked a Go-based backend project and found that disabling these protections (Spectre/Meltdown patches) reduced wall-clock compilation times by 31.7%.

The "System Time" nearly doubled with mitigations enabled, proving that the constant context-switching required for security "handshakes" acts as a massive throttle on syscall-heavy workloads like compiling and linking.

Go Build Benchmark (`time go build ./...`)

Metric	Mitigations OFF	Mitigations ON (Default)	Delta (Penalty)
System Time	13.51s	24.89s	+84.2%
Total (Wall) Time	18.31s	26.98s	+47.3%
CPU Efficiency (higher is better)	522%	395%	-127%

The good news is that the fix is a one line change added to .wslconfig.

Read the full technical breakdown, including .wslconfig examples and perf bench audit commands, at the link below.

Full Post: The "Security Tax": Reclaiming 30% Performance in WSL 2 // Tony Metzidis

Archive Legacy Github Repos with Subtree

Tony Metzidis — Tue, 05 Aug 2025 00:47:08 +0000

If you're like me your github account is littered with hundreds of legacy experimental repos that you don't want to toss.

git subtree is the magic needed to consolidate them into an archive, preserving all of the commit history . Once consolidated, all of those legacy repos can be archived to your cloud storage and deleted from github.

Clone the Archive Repo

First step is to choose (or create) your archive repo that will contain all of your experiments

USERNAME=tony
REPO=archive
git clone git@github.com:$USERNAME/$REPO.git
cd $REPO

Clone one or more Experiment Repos (you would like to delete)

USERNAME=tony
REPO=experiment-web
git clone git@github.com:$USERNAME/$REPO.git

Add the local experiment-web as a "remote"

note: Git remotes can be copies from a local directory. This is the magical source of subtree's power to fan-in or fan-out repos

cd archive
name=experiment-web ; git remote add subtree/$name ../$name

Do this any number of times for all of your experiment Repos

Subtree The Repo and Test the Results

# stay within Archive
name=experiment-web
git subtree add -P $name subtree/$name master # or any branch

Test that all the contents match exactly

cd $name
diff -r . ../../$name
# Only in ../../experiment-web: .git

Test that the subtree'd log matches the log of the original repo

git log --graph -4
*   a19d970 - (HEAD -> master, tonymet/master) Add 'oh-my-zsh/' from commit '9f3f282699dccc11221debbdbec4be654c63ac83' (11 minutes ago) <tony>
|\
| * 9f3f282 - (subtree/oh-my-zsh-origin/anthony) macbook (14 minutes ago)

Archive and Delete The Repo

Now you can archive the repo to your cloud storage ( Google Cloud , etc).

# Save to TGZ file and copy to your Google Drive
name=experiment-web && tar -zcf archive/$name-`date +%Y-%m-%d`.tgz $name &&  rm -rf $name  
# Visit repo on the web to delete

How to Put Everything in Git

Tony Metzidis — Fri, 03 Jan 2025 19:21:56 +0000

It's good to get in the habit of putting everything into a git repo, and that means having a canonical remote for experiments. Creating remotes for each experiment becomes a clutter of keys and repos. So it's best to merge all of those experiments into a larger experiments repo and just push that repo to github.

Instead of thousands of repos, consolidate your configs and experiments into a single repo on your development machine like so:

In this case I needed a simple main.c to test ARM support for NEON (like SSE on intel) on Raspberry PI. The directory was primitive, but I still wanted to retain the experiment:

 - arm_neon/ 
      - main.c
      - .gitignore

To preserve this repo, I still use git init and manage commits within arm_neon locally, but "subtree" it into an experiments repo using git subtree add . Here are the steps.

1. Initialize and Commit the Experiment locally on Raspberry Pi

cd arm_neon
git init
git add -u
git commit -m "arm register test working"

2. Add the arm_neon Experiment Remote

On the development machine , add the arm_neon experiment as a remote within the experiments repo.

cd experiments
git remote add arm_neon ssh://pi@pi4.local/home/pi/test/arm_neon
git fetch arm_neon
# git warns you the two repos have nothing in common-- as expected
warning: no common commits

Add the subtree using arm_neon as the prefix (the directory)

PREFIX=arm_neon
REMOTE=arm_neon
git subtree add -P $PREFIX $REMOTE master

Test that it worked

git log -1
93dc44e - (tag: arm_neon_latest, tonymet/master) Add 'arm_neon/' from commit '083a748c92a4b04caa667c3573de4fb0c46c86fc' (33 minutes ago) <Anthony Metzidis>

3. Push the Experiments to Github

Now experiments contains arm_neon and hundreds of others. Push it up to github.

git push github HEAD

4. Continue Experimentation & Tracking Changes

Now that the two repos are linked, you can continue making changes to arm_neon and use git subtree merge to incorporate the latest commits.

# on raspberry pi, a new commit has been made
 git log
3d7315a - (HEAD -> master) improve docs (11 seconds ago) <Anthony Metzidis>
083a748 - arm neon call (26 minutes ago) <Anthony Metzidis>

now merge those changes into the experiments repo

# get latest changes on development machine
git fetch arm_neon
# merge those into the subtree .
git subtree merge arm_neon/master -P arm_neon

Now the experiments repo contains all the latest changes from arm_neon, and can be pushed to github.

git log -1
93dc44e - (HEAD -> master) Add 'arm_neon/' from commit '083a748c92a4b04caa667c3573de4fb0c46c86fc' (5 seconds ago) <Anthony Metzidis>

Now you have one repo that contains hundreds of experiments , rather than creating hundreds of repos in your github account.

Streaming regex scanner — regexpscanner

Tony Metzidis — Thu, 05 Dec 2024 00:10:53 +0000

Go's regexp module falls short with stream processing-- nearly all methods require a string or []byte. The regexpscanner module makes it easy to extract tokens that match regular expression patterns.

https://pkg.go.dev/github.com/tonymet/regexpscanner

Install Module

go get github.com/tonymet/regexpscanner@latest

Example Usage

use ProcessTokens when a simple callback-based stream tokenizer is needed .
ProcessTokens calls handler(string) for each matching token from the Scanner.

package main

import (
    "fmt"
    "regexp"
    "strings"

    rs "github.com/tonymet/regexpscanner"
)

func main() {
    rs.ProcessTokens(
        strings.NewReader("<html><body><p>Welcome to My Website</p></body></html>"),
        regexp.MustCompile(`</?[a-z]+>`),
        func(text string) {
            fmt.Println(text)
        })
}

Output

<html>
<body>
<p>
</p>
</body>
</html>

Give it a try and see the Go Module Page for more examples

Run godoc Automatically

Tony Metzidis — Tue, 26 Nov 2024 19:32:55 +0000

VSCode has a fantastic task runner, with lots of configuration options for when and how the task should be run.

Let's set up godoc to run whenever you open the project. It will display a push notification linking you to godoc server within your browser.

STEPS to Add

(1) Install godoc via your terminal

 go install golang.org/x/tools/cmd/godoc@latest

(2) Add the task with CTRL-SHIFT-P, "Configure Tasks" . This edits ./vscode/tasks.json
(3) Add the following task to the tasks array (copy the individual task object below)

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "godoc",
            "type": "shell",
            "command": "godoc",
            "options": {
                "cwd": "${workspaceFolder}",
                "shell": {
                    "args": ["-c"],
                    "executable": "/bin/sh"
                }
            },
            "runOptions": {"runOn": "folderOpen"},
            "presentation": {
                "echo": true,
                "reveal": "never",
                "focus": false,
                "panel": "shared",
                "showReuseMessage": true,
                "clear": false
            },
            "problemMatcher": []
        }
    ]
}

(4) Run the task. You can run the task with CTRL-SHIFT-P → "Run Task" → "godoc" or by reopening your window. A notice will show linking you to godoc. Or you can find the link using the "Ports" tab and clicking the godoc URL.

Fighting GCP & Firebase Cloud Client CLI and SDK Bloat

Tony Metzidis — Fri, 18 Oct 2024 07:00:00 +0000

Client CLIs & SDKs for GCP, Firebase and other clouds are terribly bloated. GCP includes a python distro, firebase includes node+npm. This goes unnoticed on overpowered devboxes, but impacts your cloud bill with storage, vcpu, wall-time and transfer fees. If you are trying to downsize your VMs, you will find that the client SDK/ CLI pre-requisites will often hang your machine terminal by exausting vcpu and iops budgets. Cloud container services are often storage-limited to ram-disks--so CLI installs consume what little you have.

To combat the bloat, I've started a few projects to offer lightweight solutions

gcloud-lite -- a stripped distro of gcloud cli that is 90% smaller
gcloud-go -- a 90% smaller and faster go binary for deploying to firebase and gcloud

Benchmarks

For example, e2-medium VMs using gcloud-lite are 86% faster to install the cli. This means your work can start nearly 90s faster than using the default CLI. You can downsize to x-small VMs which can save up to 75%

Image	Install Time	Improvement
google-cloud-cli	1m29s	-
gcloud-lite	12.6s	86%

For firebase deployments, the image is 92% smaller, and startup is faster, meaning you can downsize VMs and container jobs will execute > 50% faster

docker image	size	savings
firebase-tools	245mb	n/a
gcloud-go	19mb	92%

Reduced Storage

Runnable docker image — 93% smaller
tgz tarball — 75% smaller

How You Can Help

Please start testing the projects, and file a feature request. Patches are welcome , and please share how the lightweight CLI tools are helping your project

WSL2 Backup to OneDrive Cloud

Tony Metzidis — Wed, 31 Jan 2024 08:00:00 +0000

WSL2 provides great disk performance, but it requires storing the files separately in a virtual disk that is not accessible by OneDrive. WSL2 can be backed up with wsl --export Debian to a VHD or TGZ, but that is a complete disk backup of 20gb or more -- not scalable for hourly backups.

With this approach, we use Windows Task Scheduler to trigger robocopy to incrementally sync directories from WSL2 to Onedrive's native FS, so incremental copies are fast ( 1 s per 10k files), and OneDrive sync time remains negligible.

It's also useful for snapshotting subdirectories to TGZ for offline or cloud archiving.

Robocopy

robocopy is a built-in tool that recognizes file size & modification times to copy changes incrementally./xd param is used to exclude node_modules (wasteful JS library artifacts)

This script syncs a project directory /home/USERNAME/sotion within WSL2 to$HOME\OneDrive\Documents\sotion on Windows

# backup wsl contents on a schedule
# set & truncate $logfile
$logfile="$HOME\backup-wsl.log.txt"
if ((Get-Item $logfile).length -gt 128000){
    Remove-Item $logfile
}
$src="\\wsl.localhost\Debian\home\${env:Username}\sotion"
$dest=$(Join-Path ${env:OneDrive} "Documents\Sotion")
Write-EventLog -LogName Application -Source "Backup-WSL" -EventID 3001 -Message "Starting Backup"
$t0=(Get-Date)
robocopy $src $dest /W:1 /R:0 /E /xd node_modules /NFL /NDL /LOG+:$logfile
$exitcoderobo=$LASTEXITCODE
$t1=(Get-Date)
$delta =($t1-$t0)
$message="Finished Backup. Duration = $delta"
if($exitcoderobo -ne 0){
    $message="ERROR: Finished Backup. Backup failed. Duration = $delta . Check $logfile for error"
}
Write-EventLog -LogName Application -Source "Backup-WSL" -EventID 3001 -Message $message
exit $exitcoderobo

Trigger the script to test

pwsh --noprofile backup-wsl\backup-wsl.ps1

Create the Scheduled Task

$time = New-ScheduledTaskTrigger -Daily -At 2pm 
$user = (whoami)
$action = New-ScheduledTaskAction -Execute "${env:ProgramFiles}\PowerShell\7\pwsh.exe" -Argument "-noninteractive -nologo -noprofile $HOME\scripts\backup-wsl\backup-wsl.ps1"
Register-ScheduledTask -TaskName "Backup-WSL" -Trigger $Time -User $User -Action $action

Trigger the script to create the task schedule

 pwsh -noprofile .\backup-wsl\schedule-backup.ps1

Create the Event Log

New-EventLog -LogName Application -Source "Backup-WSL"

Monitoring

Runs are logged to Windows Event Viewer. You can view them using the Event Viewer app or Get-EventLog

> get-eventlog -Source backup-wsl -LogName Application -Newest 1 |Select-Object message

Message
-------
ERROR: Finished Backup. Backup failed. Duration = 00:00:01.8787580 . Check C:\Users\xxx\backup-wsl.log.txt for err…

Full Example

See this Gist

Setting for "Bob made a new post..." notification?

Tony Metzidis — Tue, 28 Nov 2023 00:24:57 +0000

Is there a setting to disable this notification type?

Here are the settings that I have available ...

IPV6 Migration Guide for Developers using AWS EC2 -- A Primer

Tony Metzidis — Mon, 20 Nov 2023 21:03:56 +0000

Originally on tonym.us

With the news that AWS will be now charging about $4 / instance-month for public IPv4 addresses, many
developers who procrastinated ipv6 migration are finally updating both ends of their development setup.

It's a great time to migrate, as all the intermediate infrastructure now supports IPV6 readily. Moreover, you'll benefit from permanent , global
addresses for your development instances.

Pros

A single, global, stable address for EC2 instances that never changes. No need for dynamic DNS and other hacks
No need to pay for Elastic IP addresses on dev instances
Global addressing for mutual duplex services (no more NAT needed)
Better flexibility and clarity for addressing, including Link Local & local addresses

Cons

Time needed to migrate infra to IPV6
Clumsier & less-memorable addresses, with unfamiliar idioms (e.g. no more using 127.0.0.1 or 192.168.1.1 -- though there are replacements) inherent
Bugs in legacy code that assumes 32 bit & string-representations of ipv4 addresses

Concepts & Approach

In theory, IPV6 uses 128bit addresses in place of 32 bit. Most of the
intermediate infra (ISP, backbone) is now compatible. The two areas of attention
for developers would be the server side with AWS , and the client side with your
home/office network.

The two subject areas needing attention for developers are addressing & routing.
On the server side this means dealing with addressing on EC2, VPC, VPC subnets &
routing tables, and on your home/office network updating your home router config
to obtain & allocate IPV6 addresses.

Updating the Client Side

Home routers within the past 5 years support IPV6 in settings, though usually disabled for simplicity. Once enabled the WAN & LAN will receive two addreses.

Be sure to select NATIVE instead of PASSTHROUGH to get complete IPV6 support

Test your config using Test IPV6 . At this point you
should have an IPV6 address for your WAN. This will be necessary for routing &
security groups on the AWS side

VPC Changes

AWS provides a thorough guide for migrating to IPV6

Update VPC with an IPV6 allocation
Update each subnet with a IPV6 subnet allocation -- be sure to resize and order the subnets to the scale needed . Be sure to disable IPV4 auto address allocation, and enable IPV6 address allocation
Update the routing tables to add the V6 ::/0 route
Update your security groups to add your client-side WAN IPV6 IP
Choose an instance to update to IPV6 addressing. this will help you test the e2e VPC routing & addressing config

At this point you should be able to ping & SSH to the test instance using all IPV6 addressing

EC2 Changes

The EC2 change above will work to add IPV6 addresses to instances, but they will still acquire IPV4 addresses until they are re-launched. This means you'll still be paying for public IPV4 IPs -- about $4 additional per instance-month

To release public IPV4 IPs, the instances will need to be re-launched.

Quickly Relaunch EC2 Instances Using AMI

Stop (do not terminate) each instance
Choose Actions → Images & Templates → Create Image
create AMI
Launch new instance with AMI. Test IPV6 address & confirm no IPV4 address was allocated
[optional] If the instance has multiple volumes, detach the volume & re-attach to the new instance with the same device ID
Mark the old instance for termination on a later date

Review IPV4 Address Allocation & Billing

Once the EC2 migration is complete, review IPV4 address usage using VPC IP
Address
Manager
and AWS Billing Cost
Explorer (group
by API to see EC2 networking costs)

More Resources & Guides

Improve WSL Security with Read-Only Filesystem

Tony Metzidis — Wed, 04 Oct 2023 19:30:00 +0000

Originally on tonym.us

By default, all Windows drives are mounted with read & write access (rw) within WSL . Though this is convenient for beginners, it opens up VM shell attacks on your Windows host files.

Instead, we can disable the auto mount feature using wsl.conf and selectively add read-only drives inside the WSL VM using /etc/fstab

Overview

Deactivate "auto mount" in /etc/wsl.conf
Enable fstab using MOUNTfStAB = true in wsl.conf
test config files and mounting work well
reboot the wsl VM to complete the setup

Example WSL Config `wsl.conf`

Place this inside the /etc/ directory on the WSL VM

# Automatically mount Windows drive when the distribution is launched
[automount]

# disable auto-mounting of c:
enabled = false

# process fstab entries
mountFsTab = true

# disable launching windows exe files
[interop]
enabled = false
appendWindowsPath = false

Example `/etc/fstab`

First, make the target directory

$ mkdir -p /mnt/Users/USERNAME/Downloads

Add the entry to /etc/fstab

#file system dir type options dump pass
# READ ONLY MOUNTS
c:\\Users\\USERNAME\\Downloads /mnt/Users/USERNAME/Downloads drvfs defaults,ro 0 0

Testing FSTAB Before Launch

Test by un-mounting and re-mounting via fstab

$ umount /mnt/Users/USERNAME/Downloads
$ mount -a # mount fstab entries
$ ls -l /mnt/Users/USERNAME/Downloads

this should produce no errors and show the expected files at the target directory

Re-launch WSL to Complete Test

OUTSIDE the VM, run wsl --shutdown DISTRO. You can launch the VM by opening a new WSL tab in Windows terminal or via start menu

More Information on WSL-Conf

Full details on the wsl config file can be found on MS' Documentation for wsl.config

Smokeping On Raspberry Pi Zero

Tony Metzidis — Wed, 18 Jan 2023 08:00:00 +0000

Smokeping is a self-contained network monitoring app , capable of monitoring using ICMP/Ping, HTTP, DNS -- as well as other signals generated from CLI monitoring tools (e.g. curl, dig, mtr etc). It provides a web-based monitoring UI to chart the probe measurements so no further monitoring apps (like Prometheus) are needed.

Running smokeping on a $5 Raspberry Pi Zero is a fun experiment in lightweight computing . Using Apache Mod FastCGI makes the app usable on the meager hardware.

By the end of the exercise you'll have the smokeping probes running to test network performance and the UX available on your local network onhttp://raspberrypi.local/smokeping

Prerequisites

Pi Zero
MicroSD 4GB+
A windows or mac machine to run image installation & configuration
wifi for installing packages

1. Install RaspberryPi OS using the Imager

Download & Install Raspberry Pi Imager
Select RaspberryPi OS Lite 32bit from the Advanced menu
[new] Use the cog / settings menu to enable SSH, set hostname & set WIFI credentials . ⚠️ Don't Skip this step: RaspberryPi OS no longer supports default user credentials.
Write the image to your Micro SD

2. Boot & SSH into the device and update the device (optional)

SSH into the device e.g. ssh pi@raspberrypi.local
update your catalog sudo apt update
(optional ~15min) update your installed packages sudo apt upgrade

3. Install smokeping, apache2 & fastCGI

install apache, smokeping & fast-cgi (to improve loading times) \ $ sudo apt install apache2 fping curl smokeping libapache2-mod-fcgid
enable smokeping $ sudo a2enconf smokeping
restart and test that smokeping default site is working by visiting http://raspberrypi.local/ in your browser

At this point you will see the default smokeping installation with minimal example probes

4 Enable smokeping configuration

activate fastcgi and set smokeping to default by adding this block to/etc/apache2/conf-available/smokeping.conf (after Line 3)

# redirect / to /smokeping 
RedirectMatch ^/$ /smokeping/
# activate fastcgi to improve performance
<Location /smokeping/smokeping.cgi>
    SetHandler fcgid-script
</Location>

5 Edit Targets and Test

Here is the example head of the Targets config to probe your home router

$ head -n 19 /etc/smokeping/config.d/Targets 
***Targets***

probe = FPing

menu = Top
title = Network Latency Grapher
remark = Welcome to the SmokePing website of WORKS Company. \
         Here you will learn all about the latency of our network.

+ Home

menu = Home
title = Home

++ Gateway
menu = Gateway
title = Gateway
host = 192.168.1.1

6 Follow Up & Next Steps

At this point your probes should be running regularly and collecting historical measurements.

I recommend adding the following probes

Your ISP's first and second HOPs (use traceroute to identify the IP addresses)
any streaming services e.g. Netflix, Youtube
Assign fixed IPs to your devices like PS4, laptop, phone and probe them in your home to catch performance issues.