Redis Upstash Free hit limit in one day

[blackmouse572]

The upstash offer quite generous free tier with

• Max 500K commands per month
• Max 256MB data size
• One free database per account

After deploy to railways for 1 days (1 instances with serverless turn on)

After i check here is the current log

[Gzerox]

Hello @blackmouse572 ,

I’m not currently using the Redis service myself, but I’ll try to help.

Assuming no extra customizations beyond what’s in the repository, Redis appears to be used mainly by the SessionService, particularly in the following methods:

1. findLoginSession
2. setLoginSession
3. deleteLoginSession
4. resetLoginSession

Notably, some of these methods are invoked multiple times during operations like:

1. updateManyRevokeByUser

Expected Redis Usage

Based on the current logic, here’s an overview of Redis interactions during a typical session:

1. Login: setLoginSession is called, setting a key with expiration based on refreshTokenExpiration.
2. Session Refresh: the refresh endpoint triggers findLoginSession.
3. Session Expiry: Redis eventually removes the session key after expiration.

Assuming a refreshTokenExpiration of 15 minutes, a single user continuously browsing for 8 hours would result in about 34 Redis commands/interactions.

---

That said, I’d be very surprised if the application’s normal behavior alone accounts for hitting the 500K limit so quickly.

Im almost confident the reason for reaching the high number of usage is related to some external IDE used to interact with redis, or even the upstash backend/console such as: dashboard, browser, scan operations and so on.

Please take look:

1. https://upstash.com/docs/redis/troubleshooting/command_count_increases_unexpectedly

Hope this helps!

[blackmouse572]

Hello @blackmouse572 ,

I’m not currently using the Redis service myself, but I’ll try to help.

Assuming no extra customizations beyond what’s in the repository, Redis appears to be used mainly by the SessionService, particularly in the following methods:

1. findLoginSession
2. setLoginSession
3. deleteLoginSession
4. resetLoginSession

Notably, some of these methods are invoked multiple times during operations like:

1. updateManyRevokeByUser

Expected Redis Usage

Based on the current logic, here’s an overview of Redis interactions during a typical session:

1. Login: setLoginSession is called, setting a key with expiration based on refreshTokenExpiration.
2. Session Refresh: the refresh endpoint triggers findLoginSession.
3. Session Expiry: Redis eventually removes the session key after expiration.

Assuming a refreshTokenExpiration of 15 minutes, a single user continuously browsing for 8 hours would result in about 34 Redis commands/interactions.

That said, I’d be very surprised if the application’s normal behavior alone accounts for hitting the 500K limit so quickly.

Im almost confident the reason for reaching the high number of usage is related to some external IDE used to interact with redis, or even the upstash backend/console such as: dashboard, browser, scan operations and so on.

Please take look:

1. https://upstash.com/docs/redis/troubleshooting/command_count_increases_unexpectedly

Hope this helps!

Hi @Gzerox

For updated, after i create new account to test, after 20mins, the server had sent 9.4k commands to the Upstash with no activities (yes, no login, no logout, fresh new). I think migrate to dedicate server or something similar is good choice for pricing since Upstash charged by requests

Here is my update try to limit the call from BullMQ

@Module({
    controllers: [],
    providers: [],
    imports: [
        ConfigModule.forRoot({
            load: configs,
            isGlobal: true,
            cache: true,
            envFilePath: ['.env'],
            expandVariables: false,
        }),
        MongooseModule.forRootAsync({
            connectionName: DATABASE_CONNECTION_NAME,
            imports: [DatabaseOptionModule],
            inject: [DatabaseOptionService],
            useFactory: (databaseService: DatabaseOptionService) =>
                databaseService.createOptions(),
        }),
        BullModule.forRootAsync({
            imports: [ConfigModule],
            inject: [ConfigService],
            useFactory: (configService: ConfigService) => ({
                connection: {
                    host: configService.get<string>('redis.queue.host'),
                    port: configService.get<number>('redis.queue.port'),
                    username: configService.get<string>('redis.queue.username'),
                    password: configService.get<string>('redis.queue.password'),
                    tls: configService.get<any>('redis.queue.tls'),
                    family: 0, // Test on railways (https://docs.railway.com/reference/errors/enotfound-redis-railway-internal)
                },
                stalledInterval: 30000, // Check stalled jobs less frequently (30s)
                drainDelay: 5000,      // Increase delay between polling attempts
                skipStalledCheck: true, // Skip stalled job checks for lower Redis usage
                defaultJobOptions: {
                    backoff: {
                        type: 'exponential',
                        delay: 3000,
                    },
                    attempts: 3,
                    removeOnComplete: true, // Clean up completed jobs
                    removeOnFail: { count: 10 }, // Keep only 10 failed jobs
                },
            }),
        }),
        CacheModule.registerAsync({
            isGlobal: true,
            imports: [ConfigModule],
            useFactory: async (
                configService: ConfigService
            ): Promise<CacheOptions> => ({
                max: configService.get<number>('redis.cached.max'),
                ttl: configService.get<number>('redis.cached.ttl'),
                stores: [
                    new KeyvRedis({
                        socket: {
                            host: configService.get<string>(
                                'redis.cached.host'
                            ),
                            port: configService.get<number>(
                                'redis.cached.port'
                            ),
                            tls: configService.get<boolean>('redis.cached.tls'),
                            family: 0, // Fix for Railway DNS resolution issues
                        },
                        username: configService.get<string>(
                            'redis.cached.username'
                        ),
                        password: configService.get<string>(
                            'redis.cached.password'
                        ),
                    }),
                ],
            }),
            inject: [ConfigService],
        }),
// ....rest

[Gzerox]

You are right, somehow I forgot about BullMQ which is actually connected to Redis constantly and could easily be the culprit.

I see similar discussions here:
OptimalBits/bull#2457

I do see what you are trying to do.

Im not very familiar with this module, however if you suspect the following lines are not doing anything:

stalledInterval: 30000, // Check stalled jobs less frequently (30s)
drainDelay: 5000,      // Increase delay between polling attempts
skipStalledCheck: true, // Skip stalled job checks for lower Redis usage

I would suggest to try to move then into the various @Processor, for example:

@Processor(ENUM_WORKER_QUEUES.EMAIL_QUEUE,{
    drainDelay: 5000,
    stalledInterval: 30000,
    skipStalledCheck: true,
})
export class EmailProcessor extends WorkerHost implements IEmailProcessor {
    private readonly debug: boolean;
    private readonly logger = new Logger(EmailProcessor.name);
//....
}

[blackmouse572]

Okay, thanks, I will try applied the setting to each processor. Let temp to resolved this since i move to dedicated redis server Vào Th 3, 27 thg 5, 2025 vào lúc 18:19 Loris ***@***.***> đã viết:

…

*Gzerox* left a comment (andrechristikan/ack-nestjs-boilerplate#562) <#562 (comment)> You are right, somehow I forgot about BullMQ which is actually connected to Redis constantly and could easily be the culprit. I see similar discussions here: OptimalBits/bull#2457 <OptimalBits/bull#2457> I do see what you are trying to do. Im not very familiar with this module, however if you suspect the following lines are not doing anything: stalledInterval: 30000, // Check stalled jobs less frequently (30s) drainDelay: 5000, // Increase delay between polling attempts skipStalledCheck: true, // Skip stalled job checks for lower Redis usage I would suggest to try to move then into the various @processor, for example: @processor(ENUM_WORKER_QUEUES.EMAIL_QUEUE,{ drainDelay: 5000, stalledInterval: 30000, skipStalledCheck: true,})export class EmailProcessor extends WorkerHost implements IEmailProcessor { private readonly debug: boolean; private readonly logger = new Logger(EmailProcessor.name);//....} — Reply to this email directly, view it on GitHub <#562 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASMSBBZDJNEDXK6XMG37PVT3ARC4DAVCNFSM6AAAAAB566K7QGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMJSGE2DGMJWG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- *Nguyễn Tuấn Ngoc (Mr)* Email for jobs: ***@***.*** ***@***.***>Phone: (+84) 522 064 576 Address: Khu đô thị FPT, Ngũ Hành Sơn, Đà Nẵng GitHub blackmouse572 | Github <https://github.com/blackmouse572>Facebook: Nguyễn Tuấn Ngọc | Facebook <https://www.facebook.com/blackmouse572> Instagram: Nguyễn Tuấn Ngọc | Instagram <https://www.instagram.com/black_mouse572/>

[andrechristikan]

@Gzerox thanks for ur explanation, and u're absolutely right!
Redis is used to maintain refresh tokens and the queue (BullMQ).

When is it used?

For refresh tokens: every time users log in and refresh their tokens
For BullMQ: currently only used for email processing and scheduled tasks for token expiration

Again, @Gzerox was spot on
BullMQ is the main culprit. It continuously polls Redis even with zero activity, which explains the high command count.
BullMQ is overkill for most small applications anyway

i will try to use redis with ttl directly for token management instead of BullMQ
anw thanks for the report @blackmouse572