MongoDB $currentOp Stage

What Is $currentOp?

$currentOp is a MongoDB aggregation stage that streams live operation documents from the server—running queries, writes, aggregations, and related sessions—so you can diagnose slowness.

$currentOp = "what is MongoDB doing right now?"

db.getSiblingDB("admin").aggregate([
  { $currentOp: { allUsers: true } },
  { $match: { active: true } }
])

must run on admin database
must be the FIRST stage
allUsers: true → see everyone's ops (needs privilege)
secs_running → how long an active op has run
opid → use with db.killOp() carefully

Prefer this over deprecated db.currentOp()

How to Use $currentOp in MongoDB

Run on admin, put $currentOp first, then filter and project.

1. Switch to admin: db.getSiblingDB("admin").
2. Start with { $currentOp: { allUsers: true } } (or {} for defaults).
3. Filter with $match (e.g. active: true, secs_running).
4. Trim fields with $project; sort/limit for readable output.

Pseudocode

assert: pipeline runs on admin
assert: $currentOp is stage 1

ops = snapshot of current server operations
      (respect allUsers / idle* options)

for each op in ops:
  if later $match fails → skip
  emit op document
    { op, ns, active, secs_running?, opid?, client?, … }

Cheat Sheet

Keep these facts handy while debugging live MongoDB load.

Live Preview

Filter a sample snapshot of operations (teaching model—not a live MongoDB connection).

{ op: "query", ns: "shop.orders", secs_running: 47, active: true }
{ op: "insert", ns: "shop.orders", secs_running: 0, active: true }

Worked Walkthrough — Find a Slow Query

Goal: list active operations that have been running for at least 5 seconds, longest first.

1. Run on admin with $currentOp first
2. Keep rows where:
     active === true
     secs_running >= 5
     op in [query, command, getmore]
3. Project op, ns, secs_running, opid
4. Sort by secs_running descending

Example hit:
  { op: "query", ns: "shop.orders",
    secs_running: 47, opid: 12345 }

Optional next step (careful):
  db.killOp(12345)

MongoDB Examples

These pipelines run on the admin database and read live operation metadata from the server—not a seeded collection. Results depend on what is running when you execute them.

db.getSiblingDB("admin").aggregate([
  { $currentOp: { allUsers: true } },
  { $match: { active: true } },
  {
    $project: {
      _id: 0,
      op: 1,
      ns: 1,
      secs_running: 1,
      client: 1,
      desc: 1
    }
  },
  { $limit: 20 }
])

{
  op: "query",
  ns: "shop.orders",
  secs_running: 2,
  client: "198.51.100.1:50428",
  desc: "Conn"
}

// Common op values:
// query | insert | update | remove | command | getmore

db.getSiblingDB("admin").aggregate([
  { $currentOp: { allUsers: true } },
  {
    $match: {
      active: true,
      secs_running: { $gte: 5 },
      op: { $in: ["query", "command", "getmore"] }
    }
  },
  {
    $project: {
      op: 1,
      ns: 1,
      secs_running: 1,
      opid: 1,
      "command.filter": 1,
      "command.aggregate": 1
    }
  },
  { $sort: { secs_running: -1 } }
])

// Terminate only if you understand the impact:
// db.killOp(<opid>)

{
  op: "query",
  ns: "shop.orders",
  secs_running: 47,
  opid: 12345
}

db.getSiblingDB("admin").aggregate([
  { $currentOp: { allUsers: true } },
  {
    $match: {
      ns: "shop.orders",
      active: true
    }
  },
  {
    $project: {
      op: 1,
      secs_running: 1,
      client: 1,
      effectiveUsers: 1,
      command: 1
    }
  }
])

// Whole database with a regex:
// { $match: { ns: /^shop\./, active: true } }

ns format: "databaseName.collectionName"
example:   "shop.orders"

Use when one collection suddenly spikes CPU.

Performance Notes

Prefer narrow filters and $project so dashboards stay light. Enable idleConnections only when auditing connection pools.

Key Takeaways