What causes "11701" in gatsbyjs/gatsby?

Read the in-progress activities listed in the panic to identify which plugin/step is stuck.

11701

11701

Error message

What it means

Structured error 11701 from the stuck-status watchdog middleware. When the reporter state stays in `ActivityStatuses.InProgress` for longer than the watchdog timeout (default 10 minutes, configurable via `GATSBY_WATCHDOG_STUCK_STATUS_TIMEOUT`), the `fatalStuckStatusHandler` fires and calls `report.panic` with the in-progress activities and diagnostic output. It is Gatsby's self-terminating guard against a build that has hung.

Source

Thrown at packages/gatsby-cli/src/reporter/redux/diagnostics.ts:200

              )
              displayingStuckStatusDiagnosticWarning = false
              displayedStuckStatusDiagnosticWarning = true
            },
            stuckStatusDiagnosticTimeoutDelay
          )
        }
      }

      if (stuckStatusWatchdogTimeoutDelay) {
        if (stuckStatusWatchdogTimer) {
          clearTimeout(stuckStatusWatchdogTimer)
          stuckStatusWatchdogTimer = null
        }

        if (currentStatus === ActivityStatuses.InProgress) {
          stuckStatusWatchdogTimer = setTimeout(
            function fatalStuckStatusHandler() {
              reporter.panic({
                id: `11701`,
                context: {
                  activities: inProgressActivities(),
                  status: getStore().getState().logs.status,
                  stuckStatusDiagnosticMessage:
                    generateStuckStatusDiagnosticMessage(),
                  stuckStatusWatchdogTimeoutDelay,
                  additionalOutput: generateAdditionalOutput(),
                },
              })
            },
            stuckStatusWatchdogTimeoutDelay
          )
        }
      }
    }
  }
}

View on GitHub (pinned to 8b06340921)

Solutions

Read the in-progress activities listed in the panic to identify which plugin/step is stuck.
Investigate the named plugin: check for network hangs, unbounded loops, or worker deaths.
If the build is legitimately large, raise the timeout: `GATSBY_WATCHDOG_STUCK_STATUS_TIMEOUT=<ms>` (e.g. `1800000` for 30 min).
Clear `.cache` and rerun; if reproducible, isolate the failing plugin by disabling plugins one by one.

Example fix

# before: default 10-min watchdog trips on a large build
gatsby build

# after: raise the watchdog timeout for known-large builds
GATSBY_WATCHDOG_STUCK_STATUS_TIMEOUT=1800000 gatsby build

Defensive patterns

Strategy: validation

Validate before calling

// Size the watchdog to your build's expected worst case
const expectedMaxMs = 30 * 60 * 1000
process.env.GATSBY_WATCHDOG_STUCK_STATUS_TIMEOUT = String(expectedMaxMs)

Prevention

Identify the stuck activity named in the panic and fix its plugin.
Raise `GATSBY_WATCHDOG_STUCK_STATUS_TIMEOUT` for legitimately long builds.
Watch for worker deaths, LMDB lock contention, and unbounded source plugins.

When it happens

Trigger: A Gatsby build/develop enters `InProgress` and never transitions to idle/failed for longer than the watchdog delay. The watchdog timer (armed while status is InProgress) elapses and panics, surfacing which activities are stuck and for how long.

Common situations: A long-running query/source plugin that never completes; a worker process that died without the parent noticing; a deadlock in caching (e.g. LMDB lock); a plugin waiting on an external resource that never returns; very large builds that legitimately exceed the default timeout.

Related errors

AI-assisted analysis of gatsbyjs/gatsby@8b06340921 (2026-08-13). Data as JSON: /api/errors/bfe736768a31142a. Report an issue: GitHub.