pingui-panic

A single function to coordinate emergency behavior across your entire Node.js system.

One database connection pool exhausted and suddenly every part of your app is failing in a different way. Workers retry. Cron jobs pile up. Requests hang. Alerts fire for symptoms, not the cause. The pager keeps screaming.

Teams improvise. They bolt boolean flags onto random modules, scatter ad-hoc env checks across workers, duct-tape middleware together — and nothing talks to each other. The result is more incident debt while you're trying to put out a fire.

pingui-panic gives every part of your system one shared question to ask: "Are we in panic mode?"

Pause queues. Skip cron runs. Block requests. Trigger alerts. Log context. All from one bit of global state.

Quick start

pnpm add pingui-panic

npm install pingui-panic

import { createPanic } from 'pingui-panic'

const panic = createPanic()

panic.onActivate(() => {
  console.log('🚨 pausing all workers')
  // queue.pause()
})

await panic.activate('DB connection pool exhausted')

Check if the system is in panic from anywhere:

if (await panic.active()) {
  // skip this operation
  return
}

When the incident is resolved:

await panic.resolve()

Real-world examples

Express — block requests during incidents

import express from 'express'
import { createPanic } from 'pingui-panic'

const app = express()
const panic = createPanic()

app.use(async (req, res, next) => {
  if (await panic.active()) {
    return res.status(503).json({ error: 'System in panic mode' })
  }
  next()
})

Cron — skip scheduled jobs

import cron from 'node-cron'
import { createPanic } from 'pingui-panic'

const panic = createPanic()

cron.schedule('*/5 * * * *', async () => {
  if (await panic.active()) return
  await syncData()
})

BullMQ — pause workers on panic, resume on resolve

import { Worker } from 'bullmq'
import { createPanic } from 'pingui-panic'

const panic = createPanic()

const worker = new Worker('emails', async (job) => {
  console.log('processing', job.id)
})

panic.onActivate(async () => { await worker.pause() })
panic.onResolve(async () => { await worker.resume() })

More integrations in docs/examples.md.

API

createPanic(options?)

Creates a panic instance.

const panic = createPanic()

Optionally pass a custom store:

const panic = createPanic({ store: new RedisStore() })

panic.activate(reason: string)

Activates global panic mode. Fires all onActivate hooks.

await panic.activate('DB corruption detected')

Safe to call multiple times — subsequent calls are no-ops while already active.

panic.resolve()

Resolves panic mode. Fires all onResolve hooks. State resets to { active: false }.

await panic.resolve()

panic.active()

Returns true if the system is in panic mode.

if (await panic.active()) { /* skip */ }

panic.status()

Returns the full state object.

const state = await panic.status()
// { active: true, reason: '...', activatedAt: '2026-05-16T...' }

panic.onActivate(fn)

Registers a hook that runs when panic activates. Receives the state object.

panic.onActivate(async (state) => {
  await alert.trigger(state.reason)
})

panic.onResolve(fn)

Registers a hook that runs when panic resolves.

panic.onResolve(() => {
  console.log('All clear')
})

Philosophy

Cooperative shutdown, not forced termination.

pingui-panic doesn't kill processes or override behavior. It broadcasts a signal. Each part of your system decides how to respond. That's the difference between a controlled emergency landing and a crash.

Keep core minimal, extend via hooks.

The core is 5 methods and a state interface. Everything else — pausing, alerting, logging — lives in hooks. Swap the store to persist across processes. The library stays out of your way.

Roadmap (lightweight)

• Redis adapter — share panic state across processes and machines
• Adapters — HTTP servers, message queues, scheduled tasks
• Health-check endpoint middleware — return 503 when panicking

Open an issue or a PR. This thing is meant to grow with the people who use it.