SigNoz/signoz · error · ResourceLimitError

resource time limit exceeded, try applying filters such as s

Error message

resource time limit exceeded, try applying filters such as service.name, etc. to reduce the data size

What it means

Companion to the bytes limit: ErrResourceTimeLimitExceeded fires when a ClickHouse query runs longer than the configured wall-clock/thread-time budget. SigNoz wraps it in ResourceLimitError so callers can present the filter suggestion.

Source

Thrown at pkg/query-service/errors/clickhouse.go:9

package errors

import "errors"

var (
	// ErrResourceBytesLimitExceeded is returned when the resource bytes limit is exceeded
	ErrResourceBytesLimitExceeded = NewResourceLimitError(errors.New("resource bytes limit exceeded, try applying filters such as service.name, etc. to reduce the data size"))
	// ErrResourceTimeLimitExceeded is returned when the resource time limit is exceeded
	ErrResourceTimeLimitExceeded = NewResourceLimitError(errors.New("resource time limit exceeded, try applying filters such as service.name, etc. to reduce the data size"))
)

type ResourceLimitError struct {
	err error
}

func NewResourceLimitError(err error) error {
	return &ResourceLimitError{err: err}
}

func (e *ResourceLimitError) Error() string {
	return e.err.Error()
}

func (e *ResourceLimitError) Unwrap() error {
	return e.err
}

View on GitHub (pinned to 5069bf80b0)

Solutions

Narrow the query with service.name / operation filters and a shorter time window
Inspect ClickHouse system.query_log for the offending query's read rows and elapsed time, then add a skip index or TTL
If legitimate, raise max_execution_time (or the SigNoz time limit) and scale ClickHouse resources

Example fix

-- before
SELECT ... FROM signoz_traces WHERE timestamp > now() - INTERVAL 30 DAY
-- after
SELECT ... FROM signoz_traces WHERE serviceName = 'frontend' AND timestamp > now() - INTERVAL 1 DAY

Defensive patterns

Strategy: retry

Validate before calling

// cannot fully prevent server-side timeouts, but pre-narrow:
if window > 24*time.Hour && service == "" {
    window = 24 * time.Hour
}

Type guard

func IsResourceTimeLimit(err error) bool {
    var rle *errors.ResourceLimitError
    return errors.As(err, &rle) && errors.Is(err, errors.ErrResourceTimeLimitExceeded)
}

Try / catch

const attempts = 3
for i := 0; i < attempts; i++ {
    resp, err = runQuery(ctx, q)
    if err == nil || !IsResourceTimeLimit(err) { break }
    window /= 2 // exponential backoff via narrower range
}

Prevention

Avoid high-cardinality group-bys over long ranges
Set client-side timeouts below the server limit so errors surface locally
Use retries with progressively narrower windows or coarser step
Keep ClickHouse replicas healthy; check system.query_log for slow queries

When it happens

Trigger: Broad, high-cardinality queries (group by high-cardinality tag, regex matches over all spans) that scan within byte limits but exceed the timeout, often under cluster load or with slow disks.

Common situations: Heavy concurrent dashboards saturating ClickHouse; queries with like/regex filters that cannot use indexes; after data growth without tuning; replicas down reducing available CPU.

Related errors

AI-assisted analysis of SigNoz/signoz@5069bf80b0 (2026-08-28). Data as JSON: /api/errors/e33da90bf3427e65. Report an issue: GitHub.