DEV Community: Skojio Community

Three cron mistakes that quietly break overnight jobs

Skojio Community — Thu, 28 May 2026 22:43:25 +0000

A cron expression is five fields. How wrong can it go? Quite wrong, as it turns out — and the failure mode is usually silent. The job runs, it just runs at the wrong time, or sixty times in a row, or never on the day you actually need it.

Here are the three patterns I've watched break production overnight, and how to spot them before they bite.

Mistake 1 — Treating `*/5` as "every 5 from now"

*/5 * * * * does not mean "run every 5 minutes starting from when you save this". It means "run at minutes 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55 of every hour".

If you save the cron at 14:03 expecting the first run at 14:08, you will be wrong. The first run will be at 14:05.

Worse, */7 * * * * runs at minutes 0, 7, 14, 21, 28, 35, 42, 49, 56 — and then 0 again 4 minutes later, because the next hour resets the cycle. Anything that isn't a divisor of 60 will misbehave at the hour boundary.

Mistake 2 — Day-of-month AND day-of-week

The fifth field (day of week) and the third field (day of month) have a non-obvious interaction. If either is unrestricted (*), cron treats the other as the active filter. If both are specified, cron runs when either matches — an OR, not an AND.

So 0 9 1 * 1 does NOT mean "9am on Mondays that fall on the 1st". It means "9am on the 1st of every month, AND 9am every Monday". That's roughly 8 runs per month instead of zero or one.

If you want a true AND, you have to filter inside the script:

[ "$(date +\%u)" -eq 1 ] && /path/to/job.sh

Or use a cron-like scheduler that supports compound conditions natively (Quartz, for instance).

Mistake 3 — Timezone drift

Most cron daemons run in the system's local timezone, which is often UTC on cloud VMs and often local time on developer machines.

Two failure modes:

DST transitions. A cron set to 0 2 * * * in a region that observes daylight saving will either skip a day (spring forward) or run twice (fall back) on transition nights.
Container drift. A container's TZ defaults to UTC. If your developer laptop says BST and the production container says UTC, the same crontab runs at different wall-clock times.

The fix is to always be explicit:

# In crontab itself (Linux):
CRON_TZ=Europe/London
0 2 * * * /path/to/backup.sh

Or run everything in UTC and convert in the application layer.

A safer authoring loop

Before you commit a cron expression to production, paste it into a parser that shows you the next 10 fire times. If the times match what you expected, ship it. If they don't, you've caught the mistake before it costs you a night.

The Skojio cron helper does exactly that — paste an expression, see the next 10 fire times in your chosen timezone, plus a plain-English description of what the expression actually means. It catches all three of the mistakes above in seconds.

Recap

Mistake	How to spot it
`*/N` where N doesn't divide 60	Hour-boundary glitch
Day-of-month + day-of-week both set	More runs than expected
Implicit timezone	DST or container drift

Cron is fine when you respect it. The above three failure modes account for nearly every "why did this run / not run" Slack thread I've seen.

How to format JSON in Chrome without an extension

Skojio Community — Thu, 28 May 2026 22:43:24 +0000

Anyone who has stared at a 600-line JSON response from an API knows the moment: you want to scan it, but Chrome's default view is a single wall of text with no indentation, no folding, no hope.

You can solve this without installing anything. Three browser-native tricks cover most cases, and one free Skojio tool covers the rest.

Trick 1 — Use the DevTools Network panel

Open DevTools, switch to the Network tab, click the request that returned the JSON, then open the Response sub-tab and click the small {} pretty-print button at the bottom-left of the panel.

Chrome reformats the response in place: indentation, line breaks, the lot. No extension required.

The catch: this only works for responses Chrome captured during a network request. If you have JSON pasted from a Slack message or saved to a .json file, this trick doesn't help.

Trick 2 — Paste it into the Console

The DevTools Console gives you a real JavaScript REPL. Paste this in:

JSON.parse(`<paste your JSON here>`)

Chrome renders the parsed object as a collapsible tree. You can click to expand and collapse, search within keys with Ctrl+F, and copy individual values cleanly.

This works well for moderately sized payloads. It struggles when the JSON contains backticks (which break the template literal) or when the payload is large enough to make the console laggy.

Trick 3 — view-source: for static files

If you have JSON saved as a file or hosted somewhere static, prefix the URL with view-source::

view-source:https://api.example.com/data.json

Chrome renders it monospace with line numbers. Combined with Ctrl+F this is enough to scan structure quickly.

When the tricks fall short

The browser tricks fail when:

You want to validate the JSON, not just view it (catch missing commas, wrong quote types)
You want to minify for production (strip whitespace)
You want to compare two JSON payloads visually
You're pasting JSON with embedded backticks or other awkward characters
You want a permanent URL you can bookmark

The Skojio JSON Formatter runs entirely in your browser — no data leaves your machine — and handles all of the above in a single panel. It validates with line-number errors, lets you toggle between formatted and minified views, and you can paste anything (backticks included) without losing your mind.

Picking the right tool for the moment

Situation	Best option
API response in DevTools	Pretty-print button in Network panel
Quick tree view of pasted JSON	Console `JSON.parse(...)`
Static `.json` file	`view-source:` prefix
Validation, minification, sharing	Skojio JSON Formatter

None of these require installing an extension. Pick the one that fits the moment.

Strong passwords without a password manager — when it makes sense

Skojio Community — Thu, 28 May 2026 15:45:43 +0000

Password managers are the right answer for almost everything. They eliminate reuse, generate high-entropy secrets, and remove the human bottleneck. For 95% of accounts, install Bitwarden or 1Password and move on.

But there is a small, specific set of accounts where a password manager is the wrong answer. Knowing which ones — and how to handle them — is worth ten minutes of attention.

The accounts that don't belong in a manager

Three categories, roughly:

The master password of the manager itself. Obviously. This one lives in your head.
Your primary email recovery account. If you lose access to the manager and the recovery account is also in the manager, you have created a circular dependency that locks you out of your own life.
Disk encryption keys, root passwords, and emergency-access codes for shared systems. Anything you might need to type when your laptop won't boot, or read aloud to a colleague during an incident.

For these, you need passwords that are strong, memorable, and typeable. That's a different problem from generic account passwords.

What "strong" actually means

A password is strong because of entropy — the number of equally-likely possibilities an attacker has to try. Length contributes far more entropy than character variety, and a passphrase made of random common words can hit 70+ bits of entropy while still being typeable.

A 12-character random string like K7#m$pQ2!nXz has roughly 79 bits of entropy. A four-word passphrase like correct-horse-battery-staple has roughly 44 bits. To match the random string you need 6-7 random words.

The two-list rule

For the handful of accounts that don't belong in a manager:

List A: passphrases for things you must type frequently or under stress (login, disk unlock). 6+ random words, hyphenated, lowercase.
List B: high-entropy strings for things stored in a sealed envelope in a safe, never typed (root password, recovery codes). 24+ random characters.

For List A you can generate offline with shuf or a wordlist. For List B you want a generator that runs in your browser so the secret never crosses the network.

The Skojio password generator runs entirely client-side — no analytics, no server round trip — and supports both modes: configurable random strings and word-based passphrases. Use it once for each account on either list, write the result down on paper, store it appropriately.

What "appropriately" means

For List A passphrases: nothing. Memorise them. If you can't, the passphrase is too long; pick a shorter one.

For List B strings: a paper backup in a physically secure location. A safe deposit box, a fire-safe at home, a sealed envelope with a trusted person. Two copies in different locations is better than one.

If the password ever needs to be typed by a human in an emergency, it belongs on List A. If it can be copy-pasted from paper, List B is fine.

What about MFA?

MFA does not replace a strong password — it complements it. Every account that supports MFA should have it enabled, regardless of which list its password lives on. The categories above are about the password; the second factor is a separate layer.

Recap

Account type	Where the password lives
Generic web account	Password manager, randomly generated
Password manager itself	In your head
Email recovery account	In your head + paper backup
Disk encryption, root, emergency	Paper backup, never in the manager

The manager handles the 95% case beautifully. The 5% needs a different tool and a different storage strategy, and confusing the two is how people end up locked out of their own accounts.

DEV Community: Skojio Community

Three cron mistakes that quietly break overnight jobs

Mistake 1 — Treating */5 as "every 5 from now"

Mistake 2 — Day-of-month AND day-of-week

Mistake 3 — Timezone drift

A safer authoring loop

Recap

How to format JSON in Chrome without an extension

Trick 1 — Use the DevTools Network panel

Trick 2 — Paste it into the Console

Trick 3 — view-source: for static files

When the tricks fall short

Picking the right tool for the moment

Strong passwords without a password manager — when it makes sense

The accounts that don't belong in a manager

What "strong" actually means

The two-list rule

What "appropriately" means

What about MFA?

Recap

Mistake 1 — Treating `*/5` as "every 5 from now"