Inconsistent behavior of window.alert() during Nuxt navigation guards

Direct answer

Nuxt 3 runs navigation guards on the server during SSR and again on the client during hydration. The window.alert() API only exists in the browser, so it is ignored on the server and may fire multiple times if the guard re‑executes during hydration. To guarantee a single client‑side alert, guard the call with process.client and defer it until after the navigation transition finishes.

Confirmed facts

• Nuxt 3 renders on the server first; any window‑dependent code has no effect there.
• Navigation guards (defineNuxtRouteMiddleware, router guards) run after route matching, both on the server and again on the client during hydration.
• During hydration, client‑only code can execute more than once if the guard triggers a re‑navigation or if the component mounts multiple times.

Likely explanation

The inconsistency you see stems from the server‑client split: the alert is either suppressed on the server or fires repeatedly as the client reconciles the SSR markup.

Steps to ensure exactly‑once alert

1. Wrap the alert in a client‑only check: if (process.client) { … }.
2. Defer the call so the router has finished the DOM update: use nextTick() or a setTimeout(() => { … }, 0).
3. Make sure you still call next() (or return) to let navigation continue.

Example middleware

// middleware/alert-guard.js

export default defineNuxtRouteMiddleware((to, from) => {
  if (process.client) {
    // Wait for hydration/transition to settle
    nextTick(() => {
      window.alert(`Navigating to ${to.path}`);
    });
  }
  return true; // Continue navigation
});

Diagnostic question: Is the alert placed in global middleware or a page‑level route guard? The answer determines whether you should use defineNuxtRouteMiddleware (as shown) or an onMounted hook inside a component.