DEV Community: 김병진

Why Your Cron Job Runs at the Wrong Time (Even When the Expression Is Correct)

김병진 — Sat, 24 Oct 2026 05:19:41 +0000

You write a cron expression, deploy your application, and expect a task to run at 9 AM.

But it runs at 6 PM.

The expression is valid. The scheduler is working.

So what went wrong?

Often, the problem isn't the cron syntax. It's the assumptions around it.

Here are three common scheduling mistakes.

A cron expression doesn't specify a timezone

Consider this expression:

0 9 * * *

In a traditional five-field cron format, this means:

Run every day at 09:00.

But 09:00 in which timezone?

That depends on the environment and scheduler configuration.

If your server interprets the schedule in UTC, the task runs at 09:00 UTC.

For users in South Korea, that's 18:00 KST.

The cron expression itself isn't wrong. It just doesn't contain the timezone information you expected.

Every 15 minutes doesn't mean 15 minutes after deployment

Consider:

*/15 * * * *

This means the job runs at minute 0, 15, 30, and 45 of each hour.

If you deploy at 10:07, it doesn't wait until 10:22.

The next scheduled execution is 10:15.

This difference matters when developers confuse fixed schedules with interval timers.

Cron describes matching clock times, not elapsed time since an application started.

Daylight saving time can change the result

Imagine a daily task scheduled for 02:30 in a timezone that observes daylight saving time.

On the spring transition, that local time may not exist.

During the autumn transition, some local times occur twice.

Different schedulers handle these situations differently.

Depending on the implementation and configuration, a job can be skipped, repeated, or adjusted.

For time-sensitive operations, never assume that every local day contains exactly 24 hours.

How to avoid surprises

Before deploying a cron schedule:

Confirm whether your scheduler uses UTC, server-local time, or a configured timezone.

Check the next several execution times.

Verify whether your scheduler uses five-field or six-field expressions.

Document your intended timezone alongside the schedule.

Test daylight saving transitions if the job operates in affected regions.

For example, this JavaScript snippet shows how to display a UTC timestamp in Seoul time:

const date = new Date("2026-10-23T09:00:00Z");

const formatted = new Intl.DateTimeFormat("en-GB", {
timeZone: "Asia/Seoul",
dateStyle: "medium",
timeStyle: "short"
}).format(date);

console.log(formatted);

It displays 18:00 in Seoul.

When debugging a scheduled task, always separate two questions:

What does the cron expression mean?

Which timezone does the scheduler use to interpret it?

Both need to be correct.

Preview your cron schedule

I built a browser-based Cron Generator as part of DevRivet to help create expressions, understand their meaning, and preview upcoming execution times.

https://devrivettools.com/cron-generator

It's a convenient way to check expressions before using them in your application. Always verify the actual scheduler's timezone and cron dialect before deployment.

What's the most confusing cron scheduling issue you've encountered?

Generating 1,000 UUIDs for Test Data? Check These 4 Things First

김병진 — Sat, 24 Oct 2026 05:18:45 +0000

Sometimes you don't need another test-data library. You just need 1,000 unique identifiers to populate a database, test an API, or build a realistic mock dataset.

Generating them is easy. Making sure they're suitable for your tests takes a little more thought.

Here are four things worth checking.

Choose the right UUID version

UUID v4 and UUID v7 are both 128-bit identifiers, but they have different characteristics.

UUID v4 is random-based.

It's a straightforward choice when you need independent identifiers without encoding creation time.

UUID v7 includes a Unix timestamp in milliseconds, followed by additional bits.

This makes v7 identifiers naturally group by generation time, which may improve index locality in certain database workloads.

However, v7 doesn't guarantee exact generation order for identifiers created within the same millisecond unless the generator implements additional monotonic behavior.

For disposable test data, either version can work. Choose based on what your application actually expects.

Check for duplicates

Even if your UUID generator is designed to produce unique values, verifying the output is useful when preparing a test fixture.

In JavaScript, you can check a generated list like this:

const ids = [
// Paste your generated UUID strings here
];

const uniqueCount = new Set(
ids.map(id => id.toLowerCase())
).size;

console.log({
total: ids.length,
unique: uniqueCount,
duplicates: ids.length - uniqueCount
});

A proper test fixture should contain the number of unique identifiers you expected.

Validate the UUID format

A string containing hexadecimal characters isn't automatically a valid UUID.

For a simple format check supporting UUID v4 and v7:

const uuidPattern =
/^[0-9a-f]{8}-[0-9a-f]{4}-[47][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i;

const invalidIds = ids.filter(
id => !uuidPattern.test(id)
);

console.log("Invalid IDs:", invalidIds);

This checks the canonical structure, version, and variant bits. It doesn't prove that an identifier was generated securely.

Don't confuse UUIDs with security tokens

UUIDs are identifiers, not a replacement for authorization.

Even if an identifier is difficult to guess, your application still needs proper access controls.

UUID v7 also reveals an approximate creation timestamp, which can matter if creation time is sensitive.

For password reset tokens or API secrets, use a security-specific token-generation approach instead of treating ordinary database IDs as secrets.

Generating test IDs quickly

For UUID v4, modern JavaScript environments provide:

const ids = Array.from(
{ length: 1000 },
() => crypto.randomUUID()
);

If you specifically need UUID v7, use a generator that implements RFC 9562.

I built a small browser-based tool that supports UUID v4, UUID v7, bulk generation, and validation without requiring a signup:

https://devrivettools.com/uuid-generator

It's useful when you want to prepare sample IDs without setting up a separate script.

What do you normally use for database IDs: integers, UUID v4, or UUID v7?

Why a Regex Tester Can Freeze Your Browser Tab

김병진 — Fri, 23 Oct 2026 03:39:45 +0000

nnot interrupt a synchronous regex operation that is already blocking the same thread.

A practical approach: Web Workers

One way to reduce the risk of freezing the interface is to move regex execution into a dedicated Web Worker.

The main page sends the pattern, flags, and test text to the worker. The worker evaluates the expression and returns the matches.

If execution takes too long, the main page can terminate the worker.

For example, a regex tester can enforce a 1.5-second limit, then show a timeout message rather than leaving the interface frozen.

This approach has limitations. A timeout does not prove that a regex is efficient or safe to use with arbitrary production input. It only provides a useful execution boundary for the testing interface.

Other useful safeguards

A practical regex tester should also handle invalid expressions, zero-length matches, and large result sets.

Capping the displayed match count prevents an unexpectedly large match list from overwhelming the interface.

Capture groups and match positions are especially useful when debugging expressions against realistic sample data.

Try it in a browser

I recently built a small browser-based Regex Tester as part of DevRivet. It runs JavaScript regex tests in a Web Worker with a 1.5-second timeout, match highlighting, and capture-group inspection.

You can try it here:

https://devrivettools.com/regex-tester

I'd be interested in hearing what safeguards or debugging features you find most useful in regex testing tools.