Some operations timed out, details available at debug level

Error message

Some operations timed out, details available at debug level (debug.log)

What it means

MonitoringTask periodically reports timed-out monitored operations (e.g. cross-node reads/mutations that exceeded their deadlines). At WARN level it only says operations timed out; the per-operation details (name, timeout, coordinator) are emitted at DEBUG, to avoid log spam via noSpamLogger.

Source

Thrown at src/java/org/apache/cassandra/db/monitoring/MonitoringTask.java:175

    }

    @VisibleForTesting
    private void logOperations(long approxCurrentTimeNanos)
    {
        logSlowOperations(approxCurrentTimeNanos);
        logFailedOperations(approxCurrentTimeNanos);

        approxLastLogTimeNanos = approxCurrentTimeNanos;
    }

    @VisibleForTesting
    boolean logFailedOperations(long nowNanos)
    {
        AggregatedOperations failedOperations = failedOperationsQueue.popOperations();
        if (!failedOperations.isEmpty())
        {
            long elapsedNanos = nowNanos - approxLastLogTimeNanos;
            noSpamLogger.warn("Some operations timed out, details available at debug level (debug.log)");

            if (logger.isDebugEnabled())
                logger.debug("{} operations timed out in the last {} msecs:{}{}",
                            failedOperations.num(),
                             NANOSECONDS.toMillis(elapsedNanos),
                            LINE_SEPARATOR,
                            failedOperations.getLogMessage());
            return true;
        }

        return false;
    }

    @VisibleForTesting
    boolean logSlowOperations(long approxCurrentTimeNanos)
    {
        AggregatedOperations slowOperations = slowOperationsQueue.popOperations();
        if (!slowOperations.isEmpty())

View on GitHub (pinned to 88fd0f6a0e)

Solutions

Enable DEBUG logging for org.apache.cassandra.db.monitoring in logback.xml and inspect debug.log for the detailed list of timed-out operations
Raise cross_node_timeout / operation timeouts or investigate the slow component (disk I/O, network)
Check for GC pauses (gc.log), thread pool saturation, and dropped mutations around the same timestamps
Reduce load or add capacity if timeouts correlate with traffic spikes

Defensive patterns

Strategy: retry

Validate before calling

// before diagnosing, confirm clocks and timeouts are sane
if (Math.abs(clockSkewMillis) > 500) throw new IllegalStateException("Clock skew across nodes");

Try / catch

// re-run the operation when timeouts are transient
if (op.timedOut()) retry(op, backoff);

Prevention

Enable DEBUG on org.apache.cassandra.db.monitoring to get details in debug.log
Right-size cross_node timeouts to p99 latencies
Monitor GC pauses and disk I/O alongside this warning
Load-test before traffic peaks

When it happens

Trigger: Any monitored read or write operation exceeded its configured timeout within the last log interval: slow disks, network latency, GC pauses, overloaded replicas, or very low cross_node/operation timeouts in cassandra.yaml.

Common situations: Under-provisioned clusters under load; network partition or slow replica causing timeouts; operators seeing this generic warning but only checking the standard app log, not debug.log.

Understand the failure class

Background: Request timed out: what client-side request timeouts mean across libraries (Request timed out, TIMED_OUT, APITimeoutError) — this error's family across 39 libraries.

Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/8d63c43bf26c633c. Report an issue: GitHub.