It sucks when logs are hard to read, hard to correlate, and lack context.

Most production issues aren’t solved by adding more logs, but by making existing logs easier to work with: easy to scan under pressure, easy to correlate to a single request, and easy to filter with basic tools like grep.

The site loggingsucks.com does a great job explaining why logging often fails in practice. This post builds on those ideas and adds a few concrete patterns that have worked well for me in real production systems.

Make logs easy to read

Logs are produced by machines, but they’re read by humans, usually under stress.

If logs aren’t easy to scan, they fail at their primary job.

Years ago, Heroku popularized the logfmt format. It strikes a great balance between machine-friendly and human-readable logs by using simple key=value pairs:

Your eyes can instantly pick out what matters, and machines can still parse everything reliably.

Use a consistent logging format

Because of that, I’ve standardized on logfmt for most of my projects using debug-logfmt. It writes logs to stdout/stderr using logfmt, while keeping the familiar debug API:

const debug = require('debug-logfmt')('metascraper')

debug('retry', { url: 'https://kikobeats.com' })
debug.info('done', { time: Date.now() })
debug.warn('token expired', { timestamp: Date.now() })
debug.error('whoops', { message: 'expected `number`, got `NaN`' })

This gives you structured logs, no JSON noise, and logs that are easy to read and grep.

There’s one more subtle detail worth pointing out. The output is colorized:

api:lightship signalReady limit=hard signal=ready
api address=http://[::]:3000/ environment=development node=24.11.1 status=listening version=3.18.78 duration=113ms
req-frequency requests=1 perMinute=1 perSecond=0.0
api:cache key=EXA4OVNWtQz url="https://x.com/verge/status/957383241714970624&force=" authorization="Bearer lEhTGCfOo6" accept-encoding="gzip, deflate, br" host=localhost:3000 connection=keep-alive
browserless:info create proxyServer=false retry=2 timeout=8861 concurrency=1 mem="374 MB" duration=16ms
html-get prerender url=https://x.com/verge/status/957383241714970624 state=success
api:html:info get url=https://x.com/verge/status/957383241714970624 statusCode=200 mode=prerender duration=3.7s
media logo input=https://abs.twimg.com/responsive-web/client-web/icon-ios.77d25eba.png url=input type=png size=13160 height=1024 width=1024 size_pretty="13.2 kB" duration=298ms
media image input=https://pbs.twimg.com/media/DRg1OMRVwAEuwTK.jpg url=input type=jpg size=175887 height=1080 width=1080 size_pretty="176 kB" duration=296ms
cacheable-response key=EXA4OVNWtQz isHit=false isExpired=true isStale=false result=false etag="2fb1-OFTturlbVqQ0NEljteW2CSCUGNA" ifNoneMatch=undefined isModified=true
cloudflare-purge files=https://c.microlink.io/EXA4OVNWtQz.json isFulfilled=true duration=197ms
api status=200 ip=::ffff:127.0.0.1 /?url=https%3A%2F%2Fx.com%2Fverge%2Fstatus%2F957383241714970624&force= duration=5.2s size="12 kB"
browserless:info close timeout=false concurrency=0 mem="453 MB" duration=3ms

Color improves log readability and visual pattern matching, not just in your terminal. Colorized ASCII output is widely supported and works across many environments, from local development to production tooling.

Prefix logs by request lifecycle

The hardest part of logging isn’t writing logs; it’s reading the right ones.

This becomes especially painful under high concurrency, where logs from many requests are interleaved.
When debugging a single request, you usually want to see everything related to that request, in order.

The simplest solution: prefix every log line with a request ID.

Automatically prefix stdout/stderr in Node.js

In Node.js, this is surprisingly easy using AsyncLocalStorage.

The idea is simple:

• Generate a UUID per request
• Store it in async context
• Automatically prefix everything written to stdout/stderr

Here’s a minimal implementation:

'use strict'

const { AsyncLocalStorage } = require('async_hooks')
const { randomUUID } = require('crypto')

const asyncLocalStorage = new AsyncLocalStorage()

const originalStdoutWrite = process.stdout.write
const originalStderrWrite = process.stderr.write

const overrideWrite = (stream, originalWrite) => {
  stream.write = function (data, encoding, callback) {
    const store = asyncLocalStorage.getStore()
    if (store && store.logs) {
      const uuidString = store.uuid ?? ''
      store.logs.push({ stream, originalWrite, data: uuidString + ' ' + data, encoding, callback })
    } else {
      const uuid = typeof store === 'object' ? store?.uuid : store
      const uuidString = uuid ?? ''
      originalWrite.call(stream, (uuidString ? uuidString + ' ' : '') + data, encoding, callback)
    }
  }
}

overrideWrite(process.stderr, originalStderrWrite)
overrideWrite(process.stdout, originalStdoutWrite)

const getStore = () => asyncLocalStorage.getStore()

const getUUID = () => {
  const store = getStore()
  return typeof store === 'object' ? store.uuid : store
}

const withUUID = fn => asyncLocalStorage.run({ uuid: randomUUID(), logs: [] }, fn)

const flush = ({ print = true } = {}) => {
  const store = getStore()
  if (store && store.logs) {
    if (print) {
      store.logs.forEach(({ originalWrite, stream, data, encoding, callback }) => {
        originalWrite.call(stream, data, encoding, callback)
      })
    }
    store.logs = null
  }
}

module.exports = { getUUID, withUUID, flush, getStore }

Once this is in place, every log line automatically carries context.

Attach the request ID early

You only need to wrap request handling once:

const { withUUID, getUUID, flush } = require('./uuid')

module.exports = (req, res, reqFrequency) =>
  withUUID(() => {
    // Since now, any stdout/stderr is prefixed by uuid

    // associate the id with the response
    onHeaders(res, () => {
      res.setHeader('x-request-id', req.id)
    })

    onFinished(res, () => {
      // print logs conditionally
      flush({ print: sampling({ req, res }) })
    })
  })

No need to pass IDs around manually. No need to remember to log them. Logs are buffered per request and only printed when the sampling policy decides they’re worth keeping.

Once logs are buffered per request, you can decide whether they should be printed at all. This is where sampling comes in.

The goal isn’t to keep every log line. In production, that quickly becomes noisy, expensive, and hard to reason about.

But more importantly, printing logs is an I/O operation, and I/O is slow: Every time you write to stdout/stderr, you’re consuming CPU cycles and potentially blocking your process. By printing less, your application becomes faster and more responsive.

Sampling strategy

Instead, as Boris commented in the original post, sampling allows you to keep the requests that matter while still retaining a representative view of normal traffic.

Here’s the sampling strategy I use:

'use strict'

const { isProduction, PING_TIMEOUT } = require('../constant')

// Randomly sample the rest to print 20%
const sampling = isProduction ? () => Math.random() < 0.2 : () => true

module.exports = ({ req, res }) => {
  // 1. Never log 429 (Too Many Requests) - too noisy.
  if (res.statusCode === 429) return false

  // 2. Always keep errors (4xx, 5xx).
  if (res.statusCode >= 400) return true

  // 3. Always keep slow requests.
  // Anything above your p99 latency threshold.
  if (req.timestamp() >= PING_TIMEOUT) return true

  // 4. Always keep specific users.
  // VIP customers, internal testing accounts, flagged sessions.
  if (req.isPro || req.query?.force) return true

  // 5. Otherwise, use the sampling
  return sampling()
}

The rules are intentionally simple:

• Errors are never dropped.
• Slow requests are always kept.
• Privileged or explicitly flagged requests get full visibility.
• Everything else is sampled at a low, fixed rate.

Because logs are buffered per request, this decision happens once, at the end of the request lifecycle. You can log freely during execution without worrying about volume or cost.

Sampling becomes a policy decision, not something every log statement has to think about.

What the output looks like

The result is clean, readable, and trivially filterable:

4206b33e-b040-4052-9931-dc11481c1fcf api:lightship signalReady limit=hard signal=ready
4206b33e-b040-4052-9931-dc11481c1fcf api address=http://[::]:3000/ environment=development node=24.11.1 status=listening version=3.18.78 duration=113ms
4206b33e-b040-4052-9931-dc11481c1fcf req-frequency requests=1 perMinute=1 perSecond=0.0
4206b33e-b040-4052-9931-dc11481c1fcf api:cache key=EXA4OVNWtQz url="https://x.com/verge/status/957383241714970624&force=" authorization="Bearer lEhTGCfOo6" accept-encoding="gzip, deflate, br" host=localhost:3000 connection=keep-alive
4206b33e-b040-4052-9931-dc11481c1fcf browserless:info create proxyServer=false retry=2 timeout=8861 concurrency=1 mem="374 MB" duration=16ms
4206b33e-b040-4052-9931-dc11481c1fcf html-get prerender url=https://x.com/verge/status/957383241714970624 state=success
4206b33e-b040-4052-9931-dc11481c1fcf api:html:info get url=https://x.com/verge/status/957383241714970624 statusCode=200 mode=prerender duration=3.7s
4206b33e-b040-4052-9931-dc11481c1fcf media logo input=https://abs.twimg.com/responsive-web/client-web/icon-ios.77d25eba.png url=input type=png size=13160 height=1024 width=1024 size_pretty="13.2 kB" duration=298ms
4206b33e-b040-4052-9931-dc11481c1fcf media image input=https://pbs.twimg.com/media/DRg1OMRVwAEuwTK.jpg url=input type=jpg size=175887 height=1080 width=1080 size_pretty="176 kB" duration=296ms
4206b33e-b040-4052-9931-dc11481c1fcf cacheable-response key=EXA4OVNWtQz isHit=false isExpired=true isStale=false result=false etag="2fb1-OFTturlbVqQ0NEljteW2CSCUGNA" ifNoneMatch=undefined isModified=true
4206b33e-b040-4052-9931-dc11481c1fcf cloudflare-purge files=https://c.microlink.io/EXA4OVNWtQz.json isFulfilled=true duration=197ms
4206b33e-b040-4052-9931-dc11481c1fcf api status=200 ip=::ffff:127.0.0.1 /?url=https%3A%2F%2Fx.com%2Fverge%2Fstatus%2F957383241714970624&force= duration=5.2s size="12 kB"
4206b33e-b040-4052-9931-dc11481c1fcf browserless:info close timeout=false concurrency=0 mem="453 MB" duration=3ms

You can now:

• grep by request ID
• Copy-paste a full request trace
• Correlate client errors with server logs instantly

Recently, npm revoked all classic tokens, forcing developers to migrate to the new token format.

This creates a significant challenge if you rely on automated workflows that publish packages to npm from CI, such as automate-release. With +500 repositories under my management, manually updating each one was out of the question.

This guide shows how to automate the bulk update of NPM_TOKEN secrets across multiple GitHub repositories using github-create-secret and the GitHub API.

Get your NPM token

Before running the script, you’ll need to create a new granular access token. npm classic tokens have been permanently revoked, so you’ll need to use the new token format.

You can create a token in two ways:

1. Via the web interface: Visit https://www.npmjs.com/settings/{USER}/tokens and create a new granular token
2. Via the CLI: Use the new npm token create command (documentation available in the npm CLI docs)

For CI/CD workflows, make sure to:

• Enable the Bypass two-factor authentication (2FA) option (required for noninteractive automated workflows)
• Set an appropriate expiration (write tokens are limited to 90 days maximum)

Store it in your environment:

export NPM_TOKEN='your-new-npm-token'
export GH_TOKEN='your-github-token'

Set up the GitHub API client

We’ll use Octokit to authenticate with GitHub and fetch repository information. The client needs a GitHub personal access token with repo scope.

To create a GitHub personal access token:

1. Go to GitHub Settings → Developer settings → Personal access tokens → Tokens (classic)
2. Click Generate new token (classic)
3. Give it a descriptive name (e.g., “Bulk secret updater”)
4. Select the repo scope (this grants full control of private repositories)
5. Click Generate token and copy it immediately

Store it in your environment (along with your npm token):

export GH_TOKEN='your-github-token'

Then initialize the Octokit client:

import { Octokit } from '@octokit/rest'

const octokit = new Octokit({ auth: process.env.GH_TOKEN })

List repositories

To update secrets across multiple repositories, we first need to fetch the list of repositories from GitHub. Create a function that uses Octokit’s pagination to handle large numbers of repositories automatically.

async function listRepos (username, { withForks = false } = {}) {
  const repos = await octokit.paginate(
    octokit.rest.repos.listForAuthenticatedUser,
    {
      username,
      per_page: 100,
      type: 'all'
    }
  )

  return withForks ? repos : repos.filter(repo => !repo.fork)
}

Create secret helper function

The github-create-secret library allows you to create, update, and check repository secrets. When called without a value, it returns a boolean indicating whether the secret exists.

import createSecret from 'github-create-secret'

const createNpmTokenSecret = async (repo, opts) => {
  return await createSecret({
    owner: repo.owner.login,
    repo: repo.name,
    token: process.env.GH_TOKEN,
    name: 'NPM_TOKEN',
    ...opts
  })
}

Filter repositories by organization

Define which organizations you want to target. The script will only process repositories belonging to these organizations.

const GH_USERNAME = 'Kikobeats'

const GH_ORGANIZATIONS = [
  'kikobeats',
  'microlinkhq',
  'teslahunt',
  'urlint',
  'achojs'
]

const repos = await listRepos(GH_USERNAME).then(repos =>
  repos.filter(repo => GH_ORGANIZATIONS.includes(repo.owner.login))
)

console.log(`Found ${repos.length} repositories`)

Update secrets in bulk

The script iterates through each repository, checks if it has the NPM_TOKEN secret, and updates it if found. The upsert: true option allows overwriting existing secrets.

for (const repo of repos) {
  const hasSecret = await createNpmTokenSecret(repo)
  if (hasSecret) {
    await createNpmTokenSecret(repo, {
      value: process.env.NPM_TOKEN,
      upsert: true
    })
    console.log(`https://github.com/${repo.full_name} updated`)
  }
}

The script works by first checking if a repository has the NPM_TOKEN secret (when called without a value, createSecret returns a boolean). If the secret exists, it updates it with the new token using the upsert: true option, which allows overwriting existing secrets.

Putting all together

Here’s the complete script combining all the pieces together:

import { Octokit } from '@octokit/rest'
import createSecret from 'github-create-secret'

const octokit = new Octokit({ auth: process.env.GH_TOKEN })

async function listRepos (username) {
  const repos = await octokit.paginate(
    octokit.rest.repos.listForAuthenticatedUser,
    {
      username,
      per_page: 100,
      type: 'all'
    }
  )

  return repos.filter(repo => !repo.fork && !repo.archived)
}

const createNpmTokenSecret = async (repo, opts) => {
  return await createSecret({
    owner: repo.owner.login,
    repo: repo.name,
    token: process.env.GH_TOKEN,
    name: 'NPM_TOKEN',
    ...opts
  })
}

const GH_USERNAME = 'Kikobeats'

const GH_ORGANIZATIONS = [
  GH_USERNAME,
  'microlinkhq',
  'teslahunt',
  'urlint',
  'achojs'
]

const repos = await listRepos(GH_USERNAME).then(repos =>
  repos.filter(repo => GH_ORGANIZATIONS.includes(repo.owner.login))
)

console.log(`Found ${repos.length} repositories`)

for (const repo of repos) {
  const hasSecret = await createNpmTokenSecret(repo)
  if (hasSecret) {
    await createNpmTokenSecret(repo, {
      value: process.env.NPM_TOKEN,
      upsert: true
    })
    console.log(`https://github.com/${repo.full_name} updated`)
  }
}

This approach saved me countless hours of manual work and ensured all repositories were updated consistently.

Install ingress-nginx

First, we need an Ingress Controller. ingress-nginx acts as the entry point for your cluster, receiving external traffic and routing it to your internal services. Crucially, it also handles SSL termination, meaning it decrypts HTTPS traffic before passing it to your application.

We’ll use Helm to install it:

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --create-namespace \
  --set controller.publishService.enabled=true

After installation, your cloud provider (DigitalOcean, AWS, etc.) will provision a Load Balancer. Wait for it to be assigned an external IP:

kubectl get svc -n ingress-nginx

Look for the EXTERNAL-IP. This is the IP address you should configure in your DNS records (e.g., an A record for *.yourdomain.com pointing to this IP).

Install cert-manager

Next, we install cert-manager. This Kubernetes controller watches for certificate requests and communicates with Issuers (like Let’s Encrypt) to obtain signed certificates. It handles the complex negotiation and ensures certificates are renewed before they expire.

helm repo add jetstack https://charts.jetstack.io
helm repo update

helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --set crds.enabled=true

Verify the pods are running:

kubectl get pods -n cert-manager

Create Cloudflare API token

To issue a wildcard certificate (e.g., *.microlink.io), Let’s Encrypt requires a DNS-01 Challenge. Unlike the HTTP-01 challenge (which verifies ownership by checking a file on a web server), the DNS-01 challenge requires you to create a specific DNS TXT record.

To automate this, cert-manager needs permission to modify your DNS records.

1. Go to Cloudflare Dashboard → Profile → API Tokens and click Create Token.
2. Choose the “Edit zone DNS” preset.
3. Under Zone Resources, select the specific domain you are targeting (e.g., microlink.io).

Include → Specific Zone → microlink.io

1. Click “Continue to summary” → “Create Token” and copy the token.

Store Cloudflare API token as K8s secret

Kubernetes needs to access this token securely to communicate with the Cloudflare API. We’ll store it as a Secret in the cert-manager namespace.

Replace <YOUR_TOKEN> with the actual token you copied:

kubectl create secret generic cloudflare-api-token-secret \
  --namespace cert-manager \
  --from-literal=api-token='<YOUR_TOKEN>'

Verify the secret exists:

kubectl get secret cloudflare-api-token-secret -n cert-manager

Create ClusterIssuer

A ClusterIssuer is a Kubernetes resource that tells cert-manager who to ask for certificates (Let’s Encrypt) and how to verify ownership (using the Cloudflare DNS challenge).

We use a ClusterIssuer (instead of a namespace-scoped Issuer) so we can use it to issue certificates across all namespaces in the cluster.

Create cert-manager/cluster-issuer.yaml:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt
spec:
  acme:
    email: YOUR@EMAIL.COM
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt-account-key
    solvers:
    - dns01:
        cloudflare:
          apiTokenSecretRef:
            name: cloudflare-api-token-secret
            key: api-token

Apply it to the cluster:

kubectl apply -f cluster-issuer.yaml

Check its status to ensure it’s ready:

kubectl describe clusterissuer letsencrypt

Create Wildcard Certificate

Now we explicitly request the certificate. We’ll define a Certificate resource that specifies the domains we want (microlink.io and *.microlink.io) and points to the ClusterIssuer we just created.

Create infra/cert-manager/certificate.yaml:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: microlink-wildcard-cert
  namespace: default
spec:
  secretName: microlink-wildcard-tls
  dnsNames:
    - "microlink.io"
    - "*.microlink.io"
  issuerRef:
    name: letsencrypt
    kind: ClusterIssuer

Apply the certificate request:

kubectl apply -f infra/cert-manager/certificate.yaml

cert-manager will now start the DNS challenge process. You can watch the status:

kubectl describe certificate microlink-wildcard-cert

Once successful, the signed certificate and private key will be stored in a secret named microlink-wildcard-tls.

kubectl get secret microlink-wildcard-tls

Ingress with wildcard hosts

Finally, we configure our Ingress resource to use the generated certificate. The tls section references the microlink-wildcard-tls secret, ensuring that traffic matching our hosts is served over HTTPS.

Create infra/ingress-nginx/ingress.yaml:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: microlink-ingress
  namespace: default
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  tls:
    - hosts:
        - "microlink.io"
        - "*.microlink.io"
      secretName: microlink-wildcard-tls
  rules:
    - host: "microlink.io"
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: microlink
                port:
                  name: http
    - host: "*.microlink.io"
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: microlink
                port:
                  name: http

Apply the ingress configuration:

kubectl apply -f infra/ingress-nginx/ingress.yaml 

Your service is now accessible via HTTPS with a valid wildcard certificate!

The main advantage is that you also get YouTube Premium, so you can watch YouTube completely ad-free.

Here’s the quickest way to migrate your liked songs and configure everything properly.

1. Prepare your library

Open Spotify → go to Liked Songs → select all → Add to playlist.

This makes transferring everything much easier.

2. Set up your account

Buy YouTube Premium for €5 so you can use YouTube Music without ads and with background playback.

3. Install the desktop client

YouTube Music doesn’t have a native desktop client, but you can create one using Pake.

I used it for a tons of website that does not offer a native app. You can find YouTube Music as part of the README:

Download YouTube Music: Mac Windows Linux

4. Transfer your music

Use TuneMyMusic to transfer your Spotify playlist to YouTube Music.
Just pay for it — it works reliably and saves time.

In my case, for around 3,000 songs, just 10 was missing.

5. Reset your likes

YouTube Music might already contain some liked songs, so let’s reset them.

Go to Liked Songs, open your browser console, and run:

const delay = (ms) => new Promise(res => setTimeout(res, ms));

async function unlikeAll() {
  const items = [...document.querySelectorAll('ytmusic-responsive-list-item-renderer')];
  let count = 0;

  for (const item of items) {
    // The like / unlike button
    const likeBtn = item.querySelector('#button-shape-like button');

    if (!likeBtn) continue;

    const isLiked = likeBtn.getAttribute('aria-pressed') === 'true';

    if (isLiked) {
      likeBtn.click();
      count++;
      console.log(`Removed like #${count}`);
      await delay(400);
    }
  }

  console.log('✔ Done. If you have many songs, scroll down and run again.');
}

unlikeAll();

6. Add your new likes

Open your transferred playlist and run this in the browser console:

const delay = (ms) => new Promise(res => setTimeout(res, ms));

async function likeAll() {
  const items = [...document.querySelectorAll('ytmusic-responsive-list-item-renderer')].reverse();
  let count = 0;

  for (const item of items) {
    const likeBtn = item.querySelector('#button-shape-like button');

    if (!likeBtn) continue;

    const isLiked = likeBtn.getAttribute('aria-pressed') === 'true';

    if (!isLiked) {
      likeBtn.click();
      count++;
      console.log(`Liked #${count}`);
      await delay(400);
    }
  }

  console.log('✔ Done. If not all songs loaded, scroll down and run again.');
}

likeAll();

7. Adjust mobile settings

YouTube Music on iOS sometimes adds random songs to playlists.

To avoid this, go to: Settings → Playback and restrictions and ensure it looks like the screenshot:

And that’s it — your Spotify library should now be fully transferred and correctly liked on YouTube Music.

After spending some time understanding the different products, these are the best products on my opinion.

Why STP

Although they are more brands in the market, STP are easy to get:

• They are in many countries.
• They have YouTube channels in different languages explaining how to install them.
• The product, overall, is very good.

Products

• STP Black Silver: 1.8mm vibration damping and sound proofing.
• STP Black Gold: silver but 2.3mm.
• STP Aero: It’s Aero gold, but expensive, not worth it.
• STP Accent: 6mm/10mm heat insoluation & vibration dumping
• STP NoiseBlock: 2mm sound insulation.

Installation

It’s expected combine different products for getting better overall performance.

A commonn combination in layers is: aero silver/gold + aero accent + noise block.

There is a complete instructions section in the website.

Aerocell QP

There is a new lineup of products claiming to combine a sandwich in line layer (15 in 1), reducing the cost.

There are two options:

• Genio: 6mm for interior floor, interior doors or front wheel arches.
• Intrigo: 4mm for roof, hood, trunk, exerior doors, etc.

According with a distributor, it’s better than combine Aero + Accent.