Skip to main content

​
Redis connection refused

Causes:
  • Redis isn’t running on the specified host/port
  • The REDIS_URL points to a different host than your Celery broker
  • Firewall rules block access from the agent container to Redis
Fix:
  1. Verify Redis is running: redis-cli -h your-redis-host ping (should return PONG)
  2. Check that the URL matches your Celery broker_url setting
  3. If running the agent in Docker, ensure the container can reach Redis (use --network host or configure Docker networking)

​
Redis AUTH failed

Fix: Include credentials in the Redis URL:
If your Redis uses ACLs, the Sluice user needs read access to Celery keys. Minimum permissions:
Also grant access to your queue name keys (e.g., ~default ~payments ~notifications).

​
Agent can’t reach Sluice API

The agent needs outbound HTTPS access to sluice.sh:443. Check from inside the agent container:
If this fails, check:
  • The container has DNS resolution and internet access
  • No corporate proxy is blocking outbound HTTPS
  • Firewall allows egress to sluice.sh on port 443

​
SSL/TLS errors

This typically happens in environments with custom CA certificates (corporate proxies, self-signed certs). Fix for SDK: Set the SSL_CERT_FILE or REQUESTS_CA_BUNDLE environment variable to point to your CA bundle. Fix for agent: Mount your CA certificates into the container:

​
Broker disconnect and reconnection

The agent automatically reconnects to Redis with exponential backoff if the connection drops. You’ll see logs like:
During the disconnect window:
  • Events published to Redis PUB/SUB are lost (PUB/SUB is fire-and-forget — this is a Redis limitation, not a Sluice limitation)
  • Queue depth polling resumes immediately on reconnect
  • The agent reconciles state by scanning Redis keys after reconnection
If reconnection fails repeatedly, check that Redis is healthy and that the network path between the agent and Redis is stable.

​
Multiple Celery apps sharing one Redis

If multiple Celery applications use the same Redis instance, the agent discovers all of them. This can cause:
  • Events from unrelated applications appearing in your dashboard
  • Queue names colliding across applications
Fix: Use different Redis databases for each Celery app:
Then configure the agent’s REDIS_URL to point to the specific database for the application you want to monitor.

​
Redis Sentinel and Cluster

V0 supports standalone Redis connections only. Redis Sentinel and Redis Cluster topologies are not yet supported. Workaround for Sentinel users: Connect to the current master node directly by specifying its host and port in REDIS_URL. You can find the master address by running:
Use the returned host:port in your Redis URL. Note that if a failover occurs, you’ll need to update the URL to point to the new master (or restart the agent, which is why native Sentinel support matters). Native Sentinel and Cluster support is planned for a future release.