DEV Community: Skojio Community

99.9% Uptime: How Much Downtime Is That, Really? (Plus Combined SLA)

Skojio Community — Wed, 08 Jul 2026 10:05:35 +0000

"99.9% uptime" sounds like a small, almost meaningless gap from perfect. In practice it's the difference between an outage nobody notices and one that ends up in a postmortem. Whether you're reading a vendor's SLA, writing an incident report, or trying to work out what your app's real availability is once you account for the database, the CDN, and the auth provider it depends on, the maths behind "the nines" is simple once you see it laid out — and easy to get subtly wrong (most people average SLAs together when they should be multiplying them). This is a walkthrough of both.

99.9% uptime ("three nines") allows about 8 hours 45 minutes 36 seconds of downtime a year on the standard 365-day convention
Each extra nine cuts permitted downtime by roughly a factor of ten
For services that depend on each other, multiply availabilities together — never average them
Two services each at 99.9% combine to about 99.8%, not 99.9% — a real, common mistake
The year/month length convention you use (365 vs 365.25 days, fixed vs calendar-average month) changes every downtime figure, so check it before comparing two SLA calculators

What Does 99.9% Uptime Actually Mean?

"99.9% uptime" is a percentage of time, not a vague quality score. To turn it into something concrete, take the length of the reporting period and multiply it by the 0.1% that's allowed to be down. On the 365-day year / calendar-average month convention (30.44 days — the convention this calculator defaults to, since it's the one most billing and monitoring periods actually use):

Period	Downtime allowed at 99.9%
Daily	1 minute 26 seconds
Weekly	10 minutes 5 seconds
Monthly	43 minutes 50 seconds
Quarterly	2 hours 11 minutes 24 seconds
Yearly	8 hours 45 minutes 36 seconds

These numbers move if the convention moves. A 365.25-day year (accounting for leap years) or a fixed 30-day month instead of the 30.44-day calendar average both produce slightly different figures — which is exactly why two SLA calculators can disagree on "the same" percentage without either being wrong. Check which convention a vendor's number assumes before you compare it to your own monitoring dashboard.

The Nines, From One to Six

Each additional "nine" in an uptime percentage cuts the permitted downtime by roughly a factor of ten. Here's the full reference table, again on the 365-day convention:

SLA	Common name	Downtime per year
90%	one nine	about 36 days 12 hours
95%	one and a half nines	about 18 days 6 hours
99%	two nines	about 3 days 15 hours 36 minutes
99.5%	two and a half nines	about 1 day 19 hours 48 minutes
99.9%	three nines	8 hours 45 minutes 36 seconds
99.95%	three and a half nines	4 hours 22 minutes 48 seconds
99.99%	four nines	52 minutes 34 seconds
99.995%	four and a half nines	26 minutes 17 seconds
99.999%	five nines	5 minutes 15 seconds
99.9999%	six nines	about 32 seconds

Five nines gets quoted constantly as the gold standard for critical infrastructure — telecoms switches, payment rails — but it's worth noticing how little slack it leaves: barely five minutes a year across every dependency, not just the headline service.

How to Convert an Outage Into an Uptime Percentage

The forward direction (percentage → downtime) is the easy half. The other direction comes up just as often: you had an outage, and you need to report what percentage uptime that represents — for a postmortem, an SLA breach claim, or just your own dashboard.

The maths is the mirror image of the table above: divide the downtime by the length of the period, subtract that fraction from 1, and multiply by 100. A 42-minute outage in a 30-day month, for instance, works out to roughly 99.903% uptime for that month — comfortably inside a 99.9% SLA, but worth checking against the exact contractual period length rather than eyeballing it.

For odd, non-calendar windows — "we were down from 14:32 to 15:14 on the 12th" — a fixed day/week/month bucket doesn't apply cleanly. A custom date-range mode that takes an exact start and end timestamp plus the outage duration avoids rounding a postmortem window into the nearest calendar period.

Combined SLA for Dependent Services: Why You Can't Just Average

This is the part most SLA discussions skip, and it's where the real mistakes happen. If your application depends on a database, a CDN, and an auth provider — and any one of them failing takes the whole app down — the application's actual achievable uptime isn't the average of the three SLAs. It's their product.

Two services each individually rated at 99.9% don't combine to 99.9%. They combine to:

0.999 × 0.999 = 0.998001 → 99.8001% ≈ 99.8%

That's roughly 17.5 hours of downtime a year — about double what either service alone would suggest — simply because both need to be up at the same time, and each has its own independent chance of failing.

Add a third hard dependency and it compounds further. Three services individually rated at 99.9%, 99.99%, and 99.95% combine to:

0.999 × 0.9999 × 0.9995 ≈ 0.998401 → 99.84%

— about 14 hours of downtime a year, worse than any single link in the chain, even though two of those three services individually look excellent on paper.

This only applies to serial, hard dependencies — where the whole system genuinely fails if any one component fails. It does not apply to redundant or failover (parallel) architectures, where a single component going down doesn't take the system with it. Multiplying availabilities for a redundant setup would understate its real resilience, not overstate it — different maths for a different architecture.

Comparing Vendor SLAs Side by Side

The last piece worth flagging: when you're comparing cloud providers or hosting plans — "AWS's 99.99% vs this vendor's 99.95%" — don't stop at the headline percentage. Line up the actual downtime figures for the periods that matter to you (monthly is usually the one that maps to billing credits), and check both vendors are quoting the same year/month convention. A 0.04 percentage-point gap sounds trivial until you see it's the difference between about 4 minutes and about 22 minutes of permitted downtime a month.

Try It Yourself

Doing any of this arithmetic by hand is fiddly and easy to get subtly wrong — particularly the averaging-vs-multiplying trap above, which even experienced engineers reach for under time pressure. Skojio's SLA uptime calculator covers all five directions in one tool: forward (percentage → downtime), reverse (outage → percentage), a custom date-range mode for postmortems, a compound/chained calculator that multiplies dependent services correctly, and a side-by-side comparison table for vendor SLAs — with the year/month convention exposed as an explicit, switchable toggle rather than silently hardcoded. It runs entirely in your browser: nothing you type ever leaves your device.

If SLA maths brought you here, a few of Skojio's other free browser-based infra tools are worth a look too: the Chmod Calculator for the other everyday Linux/Unix arithmetic, the Cron Expression Helper for scheduling maintenance windows around whatever downtime budget you've got left, and the Timezone Helper for making sure "this month" means the same thing to everyone on a distributed team.

How to Generate TypeScript Types from JSON (Without Getting Optional Fields Wrong)

Skojio Community — Wed, 08 Jul 2026 10:05:03 +0000

If you've ever pasted a single JSON object into a "json to typescript" tool and gotten back a clean interface, only to have your API return a slightly different shape the next day and blow up your build — you've hit the single-sample problem. It's the most common, least talked-about failure mode in JSON-to-TypeScript conversion, and it's worth understanding before you trust any generated type in a real codebase.

What "generate TypeScript types from JSON" actually means

At its core, converting JSON to TypeScript is a structural mapping exercise. JSON has a small set of value types — string, number, boolean, null, array, object — and each one has an obvious TypeScript counterpart:

{
  "id": 42,
  "name": "Ada Lovelace",
  "active": true
}

export interface Root {
  id: number;
  name: string;
  active: boolean;
}

For a single, simple object, that's the whole job. The complexity — and the part where converters genuinely differ in quality — shows up the moment your JSON sample is an array of objects, which is the shape almost every real REST API response actually has.

The single-sample problem: why optional fields go missing

Here's the trap. Say your API returns a list of users, and one of them is missing an email field because they signed up via SSO:

[
  { "id": 1, "name": "Ada", "email": "ada@example.com" },
  { "id": 2, "name": "Alan" }
]

A converter that only looks at the first array element will produce:

export interface Root {
  id: number;
  name: string;
  email: string;
}

That's wrong — email is not guaranteed to be present, but the generated type says it is. The bug won't show up immediately. It shows up later, as a runtime undefined where TypeScript swore a string would be, because nothing forced the compiler to check the field that was actually missing in your sample data.

This is the single biggest correctness gap across the free "json to typescript interface generator" tools you'll find in a search: most infer structure from element 0 of an array (or the one object you pasted) and never look at the rest.

What correct multi-sample merging looks like

The fix is straightforward in concept, if fiddly to implement correctly: when the JSON root is an array of similar objects, merge the union of every key seen across every element — not just the first — into one interface.

export interface Root {
  id: number;
  name: string;
  email?: string; // absent from at least one sample
}

The same logic applies to types, not just presence. If a field is a number in one record and a string in another — a common pattern when an API is mid-migration, or a field is sometimes an ID and sometimes a slug — proper merging produces a union:

[{ "value": 42 }, { "value": "forty-two" }]

export interface Root {
  value: number | string;
}

A converter that samples only the first element would type value as number and quietly break the moment it saw a string. This matters just as much for nested arrays of objects: if a tags array inside one record has an item missing a weight field, that optionality has to survive being merged again when the outer records themselves get merged together — a subtlety that's easy to get right for a single level of nesting and easy to lose once you go two levels deep.

Handling JSON to TypeScript nested objects

Nested objects raise a second, separate design question: should the nested shape be written inline, or pulled out into its own named interface?

{
  "id": 1,
  "address": { "city": "London", "postcode": "SW1A 1AA" }
}

Inline keeps everything in one block:

export interface Root {
  id: number;
  address: { city: string; postcode: string };
}

Extracted gives the nested shape its own name, which is usually more readable and lets you reuse the type elsewhere:

export interface Address {
  city: string;
  postcode: string;
}

export interface Root {
  id: number;
  address: Address;
}

Extraction is generally the better default for anything beyond a trivial one-off shape, especially if the same nested structure appears under more than one property (a billingAddress and shippingAddress with identical fields, for instance) — a good tool should deduplicate those into a single interface rather than generating two identical ones with different names.

Other details worth checking before you trust a converter's output

A handful of smaller rules separate a converter that produces compiling, correct TypeScript from one that produces something that merely looks right:

Empty arrays should infer as unknown[], not silently any[] — an empty array genuinely tells you nothing about its element type, and any defeats the entire point of generating types in the first place.
Keys that aren't valid TypeScript identifiers — hyphens, spaces, a leading digit, reserved words — need automatic quoting ("last-login": string;), or the output won't compile at all.
null values should be handled explicitly, either as an honest T | null union or folded into key?: T depending on your team's convention — never silently dropped.
export and readonly should be simple toggles you control, not a hard-coded style choice you have to find-and-replace after the fact.

Try it: a json to typescript converter built around correct merging

Skojio's JSON to TypeScript Converter exists specifically to close the single-sample gap described above. Paste a JSON object or an array of objects and it will:

Merge the union of keys across every array element (not just the first) to correctly infer optional fields and unions
Recursively apply the same merging to nested arrays of objects, so optionality survives being merged at multiple levels
Let you toggle interface vs type, extract-named-interfaces vs inline nesting, export, and readonly
Automatically quote invalid-identifier keys, with a visible note when it happens
Give you a copy button and a one-click .ts download

Everything runs in your browser — nothing you paste is sent anywhere. If you want to check your JSON's shape is well-formed before generating types from it, run it through JSON Formatter & Validator first; if you'd rather get the same data into tabular CSV instead of TypeScript, JSON ↔ CSV Converter is the same-input, different-output sibling tool.

Most free JSON-to-TypeScript converters infer structure from a single sample (often just array element 0), which silently mis-types fields that are sometimes missing or sometimes a different type.
Correct multi-sample merging unions the keys across every array element: absent-in-some-records becomes key?: T, differently-typed-across-records becomes a union type.
Nested arrays of objects need the same merge logic applied recursively — optionality discovered one level down has to survive being merged again at the level above.
Extracting nested objects into named, deduplicated interfaces is usually more useful than writing them inline, especially when the same shape appears under more than one property.
Empty arrays should infer as unknown[], not any[]; invalid-identifier keys need automatic quoting, not a compile error.

How to Flatten Nested JSON to CSV (and Convert It Back Without Losing Data)

Skojio Community — Wed, 08 Jul 2026 10:05:02 +0000

Ask anyone who has piped an API response into a spreadsheet for a stakeholder how it went, and you'll usually hear the same complaint: it worked fine until the JSON had a nested object, an array, or a comma inside a text field, and then the CSV came out wrong — misaligned columns, mangled quotes, or every value turned into text. This guide covers what actually needs to happen underneath a JSON-to-CSV conversion (and the reverse), so you can either build it correctly yourself or know exactly what to look for in a tool that claims to handle it.

Why nested JSON breaks naive CSV export

CSV is fundamentally a flat, two-dimensional format — rows and columns, nothing more. JSON has no such restriction: values can be objects, arrays, or arrays of objects, nested arbitrarily deep. The moment you try to represent {"user": {"name": "Ada", "address": {"city": "London"}}} as a spreadsheet row, you have to make a decision JSON never forced you to make: how does a deeply nested value become a single flat cell, or a set of flat cells?

Most quick scripts skip this decision entirely and either crash on nested data, silently drop it, or JSON.stringify() the whole nested value into one unreadable cell without telling you that's what happened. None of those are wrong, exactly — but they're all silent, and silent conventions are exactly what breaks the moment someone else tries to read the CSV back, or tries to convert it back to JSON six months later.

Flattening nested objects: pick a separator, then be consistent

The standard approach for a nested object is dot-notation flattening: each level of nesting joins onto the column name with a separator.

{
  "name": "Ada Lovelace",
  "address": {
    "city": "London",
    "postcode": "SW1A 1AA"
  }
}

becomes three flat columns:

name,address.city,address.postcode
Ada Lovelace,London,SW1A 1AA

The separator itself (., _, or /) doesn't matter much on its own — what matters is that you use the same separator every time, and that whatever reads the CSV back into JSON knows which separator was used. A converter that lets you flatten with . today and expects _ on the way back will quietly produce the wrong nested structure, which is a much harder bug to spot than a crash.

Nested arrays: the decision most tools get wrong

Objects flatten cleanly because they have named keys. Arrays don't — and this is where "flatten JSON to CSV" tools genuinely diverge, because there are two legitimate approaches and no tool should silently pick one for you without saying so.

Index-expand. Each array item becomes its own numbered column set:

name,tags.0,tags.1,tags.2
Ada Lovelace,mathematician,writer,

This is great for short, roughly fixed-length arrays — tags, categories, a small list of phone numbers — because every item gets its own real spreadsheet column that's easy to filter and sort on.

Keep-as-JSON-text. The whole array stays as one JSON-encoded string in a single cell:

name,tags
Ada Lovelace,"[""mathematician"",""writer""]"

This preserves the array exactly — including its length — but you lose the ability to work with individual items as separate spreadsheet columns.

If your arrays vary a lot in length between records, index-expand will pad the shorter ones with empty (or null) trailing columns rather than telling you "this record only had two tags, not three." That's a structural limit of flattening arrays into columns at all, not a bug in any particular tool — if the exact length of a variable array matters to your downstream process, keep-as-JSON-text is the honest choice.

Neither option is objectively better. What matters is that the tool you use makes the choice visible and consistent, rather than burying it in a settings drawer or hard-coding one convention with no way to change it.

Custom delimiters: comma isn't universal

A plain comma is the default CSV delimiter, but it's not the only one you'll meet in practice:

Semicolon — common in locales where a comma is the decimal separator (much of continental Europe), so Excel and other spreadsheet tools there export semicolon-delimited files by default.
Tab (TSV) — a frequent choice for exports where field values themselves often contain commas.
Pipe (|) — common in older systems and log-style exports.

Whichever delimiter you use, the quoting rules (RFC 4180) still apply: any field containing the delimiter, a double quote, or a line break needs to be wrapped in quotes, with internal quotes doubled. A converter that lets you switch delimiters but forgets to re-check which characters now need quoting will produce CSV that looks fine until you open it in the one spreadsheet program that parses it strictly.

Going the other way: CSV to nested JSON, with real types

Converting CSV back to JSON has its own pitfalls, mostly because every CSV cell is, technically, just a string.

Type inference turns those strings back into real JSON types where it's safe to do so:

42, -3.5 → JSON numbers
true / false (any letter case) → JSON booleans
an empty cell → null (or an empty string, depending on your setting)

The classic trap is leading zeros. A postcode like "007" or a reference ID stored as text will silently become the number 7 if a converter blindly coerces every numeric-looking string — which is precisely the kind of quiet corruption that surfaces as a support ticket weeks later. A converter with real type inference protects leading-zero strings and gives you a "force all strings" override for cases where you don't want any coercion at all.

Nested-key reconstruction is simply flattening in reverse: an address.city column becomes a nested address object with a city key, and — if the array convention was index-expand — tags.0/tags.1 columns rebuild back into a tags array.

Round-trip fidelity: why the settings have to match on both sides

Put the two directions together and you get the real test of a JSON ↔ CSV tool: does JSON → CSV → JSON actually reproduce your original structure? This only works if the flatten and unflatten logic are literal inverses of each other — same separator, same array-handling choice, on both sides. If a tool's export and import conventions were built independently (or if you export from one tool and import with another that guesses differently), you'll get valid-looking JSON back that quietly doesn't match what you started with.

If you want to sanity-check the shape of your JSON before you flatten it — spotting an unexpectedly nested field, or validating that an API response is well-formed in the first place — a plain JSON formatter and validator is worth running first.

Try it: a converter built around round-trip fidelity

We built Skojio's JSON ↔ CSV Converter specifically to make the flatten/unflatten convention visible and symmetric instead of hidden. It supports:

Comma, semicolon, tab, pipe, or a custom delimiter, with correct RFC 4180 quoting on both read and write
A persistent, always-visible "Nested data" control for the separator and array strategy — the one setting that determines whether your round trip actually holds
Type inference on the CSV → JSON path, with leading-zero protection and a "force all strings" override
A one-click "Verify round-trip" action that sends your output straight back through the other direction, so you can see your original structure reappear

Everything runs in your browser — nothing you paste or upload is sent to a server. It's a genuinely useful complement to JSON Formatter for validating structure first, and to Base64 Encoder/Decoder if your JSON payload also needs encoding for a data URI or an API header along the way.

CSV is flat; JSON isn't — every JSON-to-CSV conversion has to make an explicit decision about how nesting becomes columns.
Nested objects flatten cleanly with a consistent separator; nested arrays need an explicit index-expand vs keep-as-JSON-text choice.
Custom delimiters (semicolon, tab, pipe) need the same RFC 4180 quoting rules as a plain comma.
Type inference on CSV → JSON must protect leading-zero strings from being coerced into numbers.
Round-trip fidelity only holds if the same separator and array-strategy settings are used on both sides of the conversion.

Chmod 755 vs 644 vs 777: What Linux File Permissions Actually Mean

Skojio Community — Tue, 07 Jul 2026 10:05:03 +0000

If you've ever pasted chmod 755 from a Stack Overflow answer without knowing why, or stared at rwxr-xr-x in an ls -l listing wondering what it's telling you, you're not alone. Linux file permissions are one of those things every developer touches constantly and understands properly only after getting burned once. This guide walks through what the numbers actually mean, when 755 is right and when 644 is right, why 777 keeps showing up in "quick fixes" that aren't actually fixes, and how to decode a permission string the moment you see one.

Each permission digit (0–7) is the sum of read (4), write (2), and execute (1)
644 — standard for regular files: owner can read/write, everyone else read-only
755 — standard for directories and scripts: owner has full access, everyone else can read and execute
777 — full access for everyone, almost never the correct answer
rwxr-xr-x is the symbolic spelling of the same permission set ls -l shows you — and it decodes to 755

How Octal Permission Numbers Work

Every Linux file or directory has three sets of permissions: one for the owner, one for the group, and one for everyone else. Each set is a single digit from 0 to 7, built by adding together the values of whichever permissions are switched on:

Value	Meaning
4	read
2	write
1	execute

So a digit of 7 means read + write + execute (4+2+1), 6 means read + write (4+2, no execute), 5 means read + execute (4+1, no write), and 0 means nothing at all. A three-digit permission like 755 is just three of these digits stacked: 7 for the owner, 5 for the group, 5 for everyone else.

A fourth, leading digit is optional and encodes the special bits — setuid, setgid, and the sticky bit — which we'll come back to further down.

Chmod 755 vs 644: When to Use Each

These two are by far the most common permission sets you'll ever set, and the difference between them is entirely the execute bit.

	Owner	Group	Other	Typical use
644	read, write	read	read	Regular files: HTML, CSS, images, config files, documents
755	read, write, execute	read, execute	read, execute	Directories, shell scripts, compiled binaries

As a rule of thumb: 644 for files, 755 for directories and anything meant to run. A directory needs its execute bit set just to be entered (cd) or listed properly — without it, even a directory you can "read" will behave strangely.

If a hosting support article tells you to "set permissions to 644", it means: the owner (usually your account or the web server user) can edit the file, and everyone else — including the web server process reading it to serve a page — can only view it. That's exactly right for a static file. Try to make that same file executable and nothing changes for how it's served; the execute bit is irrelevant to files a web server just reads and returns.

Why chmod 777 Is (Almost) Always the Wrong Answer

chmod 777 gives every user on the system — owner, group, and anyone else who can reach the file — full read, write, and execute access. On a shared server or anything reachable by a web process, that means any compromised script, any other user account, or any misconfigured process can read, overwrite, or execute that file freely.

The reason 777 shows up so often in forum "fixes" is that it genuinely does stop the permission-denied error — by removing every restriction, it removes the specific one that was actually the problem too. Almost always, the real fix is narrower: correcting file ownership (chown) so the right user owns the file, or fixing group membership so the process that needs access has it through the group permission instead of blowing the doors off for everyone. 750 or 770 — owner and group get full or read+execute access, "other" gets nothing — covers the overwhelming majority of cases people reach for 777 to solve.

Symbolic Notation: What Does rwxr-xr-x Mean?

ls -l doesn't show you octal digits — it shows you nine characters split into three groups of three, one group per owner/group/other:

rwxr-xr-x
└┬┘└┬┘└┬┘
owner group other

Each group is r, w, x if that permission is granted, or - if it isn't, always in that fixed order. So rwx is 7, r-x is 5, rw- is 6, and r-- is 4 — the same values from the octal table above, just spelled out instead of summed. rwxr-xr-x is therefore owner=7, group=5, other=5: octal 755. rw-r--r-- is 6, 4, 4: octal 644.

Reading Full ls -l Output

A real ls -l line carries more than just the permission string:

-rwxr-xr-x  1 alice staff  8192 Jun 30 09:14 deploy.sh

Breaking that down left to right:

- — the file type. - is a regular file, d is a directory, l is a symbolic link.
rwxr-xr-x — the nine-character permission string covered above (755 here).
1 — the hard-link count.
alice — the owning user.
staff — the owning group.
8192 — file size in bytes.
Jun 30 09:14 — last modified.
deploy.sh — the filename.

Once you know the shape, you can decode any ls -l line at a glance — or paste the whole line into a parser and let it do the arithmetic for you.

Setuid, Setgid, and the Sticky Bit — the Fourth Digit

Beyond the standard three digits, there's an optional fourth digit that sets three special behaviours: setuid (4) makes an executable run with its owner's privileges rather than the caller's; setgid (2) does the same for group identity and, on a directory, makes new files inherit that directory's group automatically; and the sticky bit (1) — used on shared directories like /tmp — means only a file's own owner (or root) can delete or rename it, even if everyone else can write there.

These show up in symbolic notation as a lowercase s or t replacing the execute character when the underlying execute bit is also on, or an uppercase S/T when it isn't (an unusual combination ls -l flags this way on purpose, since it's usually a mistake). It's a small enough detail that it's easier to see live than to memorise — worth playing with rather than reading about.

Try It Yourself

The fastest way to get comfortable with any of this is to stop doing the arithmetic in your head. Skojio's chmod calculator keeps the octal number, the symbolic string, and a checkbox grid all in sync as you edit any one of them, generates the exact chmod command to copy into a terminal, and — if you've got a real ls -l line or a bare permission string sitting in a hosting panel somewhere — parses it straight back into all three views so you can see exactly what it means before you touch it.

It runs entirely in your browser: nothing you type or paste is sent anywhere.

If permissions were the errand that brought you here, a few of Skojio's other free browser-based tools are worth a look too: the JSON Formatter for tidying up config and API output, the Base64 encoder/decoder for the other everyday encoding puzzle, and the Password Generator for the account-security half of "locking things down properly."

How to decode a Base64 string (4 reliable ways)

Skojio Community — Wed, 01 Jul 2026 13:19:06 +0000

You copied a blob of letters and numbers out of a config file, a JWT, or an API response, and you need to know what it actually says. It looks like gibberish — SGVsbG8sIHdvcmxkIQ== — but the trailing == gives it away: that's Base64, and it decodes back to plain text in seconds.

There are four reliable ways to decode it, depending on where you are and how awkward the string is. If you'd rather skip the command-line flags entirely, the Skojio Base64 decoder turns any string back into text or a downloadable file in one paste. Here's each method, and what to do when a string refuses to decode.

What a Base64 string actually is (and why it's not encryption)

Base64 is a binary-to-text encoding. It maps arbitrary bytes onto 64 printable ASCII characters — A–Z, a–z, 0–9, +, and / — so that binary data survives transport through systems that only accept text, like email headers, JSON fields, and URLs.

Every 3 bytes of input become 4 characters of output, which is why Base64 is always about 33% larger than the source. The = signs at the end are padding: they pad the final group up to a multiple of four characters when the input length doesn't divide evenly by three.

src="/blog/figures/base64-byte-mapping.jpg"
alt="The text 'Man' shown as three bytes, regrouped into four 6-bit chunks, and mapped to the Base64 characters T, W, F and u"
caption="Three bytes of text (24 bits) regroup into four 6-bit chunks — one Base64 character each."
/>

The critical point: Base64 has no key. It is trivially reversible by anyone, so it provides zero secrecy. A Base64-encoded password is a plaintext password with extra steps. Decoding it isn't decryption — it's just reading.

Because a Base64 string is plaintext, pasting one into a random online decoder hands your data to that server. If the blob is a JWT, an API response, or anything you'd treat as a credential, decode it locally — in the terminal, the browser console, or a client-side tool that never sends it over the network.

You'll meet Base64 most often in four places: data URIs (data:image/png;base64,… that inline an image straight into CSS or HTML), JWTs (whose header and payload are Base64url-encoded JSON), HTTP Basic Auth (the Authorization: Basic header is just base64(user:password)), and email attachments (MIME wraps binary parts in Base64). Recognising which one you're holding tells you what the decoded output should look like before you even run the command.

Decode a Base64 string in the terminal with `base64 --decode`

The fastest method on macOS and Linux is the built-in base64 command:

echo "SGVsbG8sIHdvcmxkIQ==" | base64 --decode
# → Hello, world!

src="/blog/figures/base64-terminal.jpg"
alt="A terminal showing 'echo SGVsbG8sIHdvcmxkIQ== | base64 --decode' returning 'Hello, world!', and the reverse encode command"
caption="Decoding and re-encoding 'Hello, world!' with the built-in base64 command."
/>

On older macOS the flag is capitalised:

echo "SGVsbG8sIHdvcmxkIQ==" | base64 -D

If the decoded output is binary (an image, a gzip blob), don't print it to the terminal — redirect it to a file instead:

echo "$B64" | base64 --decode > output.png

One terminal caveat: some PEM certificates and email payloads wrap Base64 at 64 characters per line. GNU base64 tolerates those newlines, but the BSD build on macOS can complain — pass -i to ignore non-alphabet characters, or strip the newlines with tr -d '\n' before piping.

On Windows, certutil or PowerShell do the same job:

[Text.Encoding]::UTF8.GetString([Convert]::FromBase64String("SGVsbG8="))

Decode Base64 in the browser console with `atob`

Already in DevTools? The browser ships a decoder: atob (ASCII-to-binary).

atob("SGVsbG8sIHdvcmxkIQ==");
// → "Hello, world!"

There's one sharp edge. atob returns a binary string, so any non-ASCII content — accented characters, emoji, anything UTF-8 — comes out mangled. The correct incantation for Unicode is:

new TextDecoder().decode(
  Uint8Array.from(atob(b64), (c) => c.charCodeAt(0))
);

If you find yourself reaching for that snippet more than once, paste the string into the Base64 tool instead — it handles UTF-8 correctly by default, so café and 🚀 round-trip without the TextDecoder dance.

Why your Base64 string won't decode — padding, URL-safe, and UTF-8

Most "invalid Base64" errors come down to three causes:

Missing padding. A valid Base64 string's length is a multiple of 4. If yours isn't, strict decoders reject it. Append = until the length divides by four — one or two signs is all it ever needs.
URL-safe variant. Base64url, used in JWTs and URL query strings, swaps + for - and / for _, and usually drops padding entirely. A standard decoder chokes on it. Convert - back to + and _ back to / first, then re-pad.
Stray whitespace. Strings copied from emails, certificates, or wrapped JSON often carry newlines or spaces. Strip them before decoding — most command-line tools fail on embedded whitespace even though the data is fine.

A JWT is the classic trap: it's three Base64url segments joined by dots. Split on the ., decode the first two segments, and you get the header and payload as JSON. The signature won't decode to anything readable — that's expected.

Data URIs hide a fourth gotcha. A string like data:image/png;base64,iVBORw0KGgo… isn't pure Base64 — the part you decode starts after the comma. Feed the whole data: prefix into a decoder and it fails; strip everything up to and including the comma first, then decode the remainder to recover the original file bytes.

If you only need to verify that a string is valid Base64 without caring about the output, check two things: the alphabet (only A–Z, a–z, 0–9, +, /, and trailing = for standard Base64) and the length-multiple-of-4 rule. Anything outside that alphabet means it's either URL-safe, corrupted, or not Base64 at all.

Decode any Base64 string in one paste

When the variant is ambiguous, the padding is missing, or the result is a file rather than text, stop fiddling with flags and paste it into a decoder that just works.

The Skojio Base64 encoder and decoder auto-detects standard and URL-safe input, fixes padding for you, decodes UTF-8 correctly, and lets you decode straight to a downloadable file for binary payloads. It runs entirely in your browser, so a JWT or an internal API token never leaves your machine — no upload, no account, no rate limit.

Recap

Where you are	How to decode
macOS / Linux terminal	`base64 --decode` (or `-D`)
Windows	`certutil -decode` or `FromBase64String`
Browser DevTools	`atob()` — wrap in `TextDecoder` for UTF-8
Awkward string, URL-safe, or a file	Skojio Base64 decoder

Base64 is an encoding, not a secret. Once you can read it on demand, the blob in your config file stops being mysterious — and when the next one resists base64 --decode, paste it into the decoder and let it sort the padding out for you.

What does a cron expression mean? Read it field by field

Skojio Community — Wed, 01 Jul 2026 13:19:05 +0000

Someone hands you 0 */2 * * 1-5 and asks "when does that run?" You can read the five fields, but the slash and the dash turn it into a small puzzle. Cron syntax is compact by design — five fields and four symbols cover almost every schedule you'll ever need — but compact means easy to misread.

The good news: a cron expression is fully decodable once you know what each field and symbol does. This guide reads one field by field. If you'd rather just paste an expression and see the answer in plain English, the Skojio cron expression helper translates it and lists the next 10 fire times instantly.

The five fields of a cron expression, left to right

A standard cron line is five space-separated fields followed by the command:

┌───────── minute        (0–59)
│ ┌─────── hour          (0–23)
│ │ ┌───── day-of-month  (1–31)
│ │ │ ┌─── month         (1–12 or JAN–DEC)
│ │ │ │ ┌─ day-of-week   (0–6 or SUN–SAT; 0 and 7 are both Sunday)
│ │ │ │ │
0 9 * * 1   /path/to/job.sh

Read positionally, never by name — cron doesn't label its fields, so 9 in the second slot is the hour, full stop. The example above means 09:00, on Mondays. Everything else is built from how each field is filled.

Count the fields first. Five means standard cron; six usually means a seconds field is bolted on the front (common in Quartz and some app schedulers). Misjudging which dialect you're in is the fastest way to read every field one position out.

How to read `*`, `,`, `-`, and `/` in any cron field

Four symbols do all the work, and they mean the same thing in every field:

* (asterisk) — every valid value. * in the hour field means every hour. * * * * * runs once a minute.
, (comma) — a list. 0,30 in minutes means "at 0 and at 30". 1,15 in day-of-month means the 1st and the 15th.
- (dash) — an inclusive range. 1-5 in day-of-week means Monday through Friday. 9-17 in hours means every hour from 9am to 5pm.
/ (slash) — a step. */15 in minutes means every 15th minute (0, 15, 30, 45). You can combine it with a range: 0-30/10 means minutes 0, 10, 20, 30.

The slash trips people up most. */15 is fixed clock positions, not an offset from when you saved the crontab — if you save at 14:07, the next run is 14:15, not 14:22. The same logic governs the three cron mistakes that break overnight jobs, so it's worth internalising early.

What `0 9 * * 1-5` means in plain English (worked example)

Take it field by field:

Field	Value	Reads as
minute	`0`	at minute 0
hour	`9`	of the 9th hour (09:00)
day-of-month	`*`	every day of the month
month	`*`	every month
day-of-week	`1-5`	Monday to Friday

Put together: 09:00 every weekday. A classic "send the morning report on business days" schedule.

src="/blog/figures/cron-anatomy.jpg"
alt="The cron expression 0 9 * * 1-5 broken into five labelled fields — minute, hour, day, month and weekday — reading as 09:00 Monday to Friday"
caption="Reading 0 9 * * 1-5 field by field: 09:00, Monday to Friday."
/>

Now read 0 */2 * * 1-5 the same way: minute 0, every 2nd hour (00:00, 02:00, 04:00 … 22:00), every weekday — so on the hour, every two hours, Monday to Friday. Reading positionally and resolving each symbol turns any expression into a sentence.

src="/blog/figures/cron-explain-terminal.jpg"
alt="A terminal translating the cron expression 0 */2 * * 1-5 into plain English: at minute 0, every 2nd hour, Monday through Friday"
caption="The same reading, automated: paste an expression, get a sentence and the next run times."
/>

One more that looks harmless but isn't: 0 0 1,15 * * means midnight on the 1st and 15th of every month — a list, not a range. Swap the comma for a dash and 0 0 1-15 * * becomes midnight on every day from the 1st to the 15th, which is fifteen runs a month instead of two. The single character is the entire difference, which is exactly why reading each symbol deliberately beats skimming.

Special strings and the optional sixth field

Many cron implementations accept named shortcuts that replace all five fields:

@hourly = 0 * * * *
@daily (or @midnight) = 0 0 * * *
@weekly = 0 0 * * 0
@monthly = 0 0 1 * *
@reboot = once, at daemon startup

You'll also see six-field expressions in the wild. Some schedulers (Quartz, Spring, many container cron images) prepend a seconds field, so */30 * * * * * means "every 30 seconds". If an expression has six fields and the first looks like a seconds step, that's why — count the fields before you read them, because a five-field parser will misread a six-field line entirely.

A couple of field-specific quirks are worth knowing too. Months and weekdays accept three-letter names: 0 0 * JAN MON is as valid as 0 0 * 1 1, and often clearer. Day-of-week is the field most likely to bite, because 0 and 7 both mean Sunday — so a range like 0-6 and 1-7 both cover the full week, just with the boundary in a different place. And ? shows up in Quartz-style expressions as a "no specific value" marker in the two day fields, used to sidestep the day-of-month-versus-day-of-week ambiguity that standard cron handles as an OR.

Read any cron expression in plain English

Reading by hand is a good skill, but the safest check before you ship a schedule is to confirm the next fire times match your intent.

The cron expression helper parses an expression, describes it in plain English, and lists the next 10 runs in your chosen timezone — which also catches the day-of-month-versus-day-of-week surprise that pure field-reading can miss. Because schedules drift across regions, pair it with the Skojio timezone helper when a job has to fire at a specific local time. Both run in your browser with no install.

Recap

Symbol	Meaning	Example
`*`	every value	`* * * * *` → every minute
`,`	list	`0,30` → at :00 and :30
`-`	inclusive range	`1-5` → Mon–Fri
`/`	step (fixed positions)	`*/15` → :00 :15 :30 :45

Five fields, four symbols, read left to right — that's the whole grammar. Once it's second nature you can decode most expressions at a glance, and when one looks ambiguous, drop it into the cron helper and let the next fire times confirm you read it right.

How to remove unused CSS and shrink your stylesheet

Skojio Community — Wed, 01 Jul 2026 13:18:34 +0000

A fresh Bootstrap build is roughly 200KB of CSS. A typical site uses maybe a tenth of it. The other 90% ships to every visitor, parses on every page load, and lingers in your bundle forever — styling components you deleted two redesigns ago.

Unused CSS is the quiet tax on your Core Web Vitals: bytes downloaded, parsed, and matched against the DOM for no reason. The good news is that most of it is findable in the browser you already have open, and removable without rewriting a line of markup. If you'd rather skip the diagnosis and just shrink the file you ship, the Skojio CSS cleaner strips comments, duplicate properties, and whitespace from any stylesheet in one paste — no upload, no build step.

Unused CSS comes in two forms: dead selectors (whole rules nothing matches) and redundant bytes inside the rules you keep.
The Chrome DevTools Coverage panel shows exactly how much of each stylesheet goes unused on a given page.
PurgeCSS removes dead selectors during a build — but it will strip classes your JavaScript adds at runtime unless you safelist them.
Minifying never deletes a rule; it only removes the bytes around the rules you keep.
You can shrink the stylesheet you ship — comments, duplicate properties, whitespace — entirely in your browser, no pipeline required.

Why unused CSS piles up in production

CSS only ever grows. Every framework you pull in, every component you ship, every A/B test you forget to clean up adds rules — and nothing in the normal workflow ever takes them back out.

Three habits do most of the damage:

Frameworks shipped whole. Bootstrap, Bulma, or an old Tailwind build without a configured content array all bundle thousands of utility classes you will never reference.
Components that outlive their markup. You delete the promo-banner component but leave its 40 lines of CSS behind, because nothing breaks when you don't.
Copy-pasted resets and vendor blocks. The same normalise rules, pasted into three stylesheets, then concatenated and minified together into one fat file.

It helps to split the waste into two kinds, because they have completely different fixes. One is a diagnosis problem — you have to work out which rules nothing uses. The other is a cleanup problem — the rules you keep are simply written with more bytes than they need.

src="/blog/figures/css-two-kinds-of-waste.jpg"
alt="A diagram splitting CSS waste into two rows: dead selectors, fixed with DevTools Coverage and PurgeCSS, and redundant bytes such as comments and duplicate properties, fixed by minifying"
caption="Dead selectors need a diagnosis tool; redundant bytes just need cleaning — and only the first needs a build step."
/>

Get the categories straight and the rest of the job is mechanical. Mixing them up is how people either ship a bloated file they think is clean, or delete a rule that turns out to matter.

How to find unused CSS in the Chrome DevTools Coverage panel

The browser ships the diagnosis tool. In Chrome or Edge, open DevTools, press Cmd+Shift+P (Ctrl+Shift+P on Windows) and run Show Coverage. Click the reload icon in the Coverage tab and interact with the page while it records.

Each stylesheet then gets a red-and-green bar. Green is bytes that matched something; red is bytes that never did. Click a file and the source view highlights the unused lines directly, so you can see which selectors are dead rather than just a percentage.

Coverage is per-page and per-interaction. It only marks a rule "used" if you actually triggered it — so open the modal, hover the dropdown, and visit the checkout before you trust the numbers. A rule that looks dead on the homepage may be the only thing styling a page you didn't click.

This is the right tool for measuring the problem, not fixing it. Coverage won't rewrite your files, and deleting by hand from a 5,000-line stylesheet is how regressions happen. Treat the panel as the audit that tells you whether the waste is worth chasing — if a stylesheet is 80% red, it is. Once you've confirmed there are real dead rules to remove, automate the removal rather than hand-editing.

Remove unused CSS in a build with PurgeCSS (and where it falls short)

The standard way to delete dead selectors automatically is PurgeCSS. It scans your markup and scripts for the class names and IDs you actually reference, then drops every rule whose selector never appears.

src="/blog/figures/css-purge-terminal.jpg"
alt="A terminal running purgecss against a 248KB stylesheet, which prints a new 31KB file after removing the dead rules"
caption="PurgeCSS scans your content for referenced selectors and rewrites the stylesheet without the dead rules."
/>

Run it against your built output and a Bootstrap-sized file routinely drops by 80–90%. Tailwind does the same thing natively now — its content array is a built-in purge step — which is why a modern Tailwind build is small even though the framework defines millions of possible utilities.

The catch is everything PurgeCSS can't see. It matches selectors as literal strings in your source, so any class name your code builds at runtime is invisible to it.

PurgeCSS strips classes added by JavaScript unless you safelist them. A line like el.classList.add('is-' + state) produces class names that appear nowhere in your source as literal text, so the matching rules get purged and the component renders unstyled in production — while looking perfect in dev, where you didn't run the purge. Add a safelist for any dynamically composed class before you trust the output.

So PurgeCSS handles dead selectors well, with a safelist as the price of admission. What it deliberately does not touch is the second kind of waste — the bytes inside the rules you're keeping.

Dead selectors are a diagnosis problem; redundant bytes are a cleanup problem — and only one of them needs a build step.

Shrink the CSS you keep — without a build pipeline

After the dead rules are gone, the file you ship is still padded with bytes that do nothing: developer comments, blank lines, four-space indentation, and duplicate declarations where the same property is set twice in one block. Minifying removes all of it without changing a single thing the browser renders.

You don't need a bundler to do this for a one-off stylesheet, a vendor file, or a snippet a designer handed you. Paste it into a client-side cleaner and get the minified version straight back. Skojio's CSS cleaner strips comments, collapses whitespace, removes duplicate properties within a block, and can sort declarations for a consistent diff — all in the browser, so the stylesheet never leaves your machine.

It won't hunt down dead selectors — that's the Coverage-and-PurgeCSS job above, because only your markup knows which rules are truly unused. But for squeezing the redundancy out of the CSS you've decided to keep, pasting the file into the cleaner is faster than wiring up a build for a file you'll process once, and it typically shaves 30–70% off the size before compression.

Recap

Kind of waste	How to remove it
Dead selectors (nothing matches)	Find with DevTools Coverage, remove with PurgeCSS
Classes added by JavaScript at runtime	Safelist them before purging
Comments, whitespace, duplicate properties	Minify and clean the stylesheet
A one-off file with no build set up	Paste into a client-side CSS cleaner

Find the dead rules in Coverage, prune them in your build, then run the file through the cleaner to squeeze out the bytes that are left. Most stylesheets come out a third smaller before you've touched a line of markup — and your visitors stop downloading two redesigns' worth of CSS they'll never see.

Schedule a meeting across time zones without the guesswork

Skojio Community — Wed, 01 Jul 2026 13:18:33 +0000

"Let's do 3pm." Whose 3pm? Yours, the colleague in San Francisco who is still asleep, or the client in Sydney for whom it is already tomorrow? A surprising share of the calendar invites that land an hour wrong start with exactly that sentence.

Coordinating a call across continents is a solved problem — you just need to see everyone's working hours at once instead of doing offset arithmetic in your head. If you'd rather skip the maths entirely, the Skojio timezone helper stacks every participant's zone on one 24-hour timeline, marks where the working days overlap, and hands you a link to share the exact slot.

Most scheduling errors come from doing UTC-offset arithmetic by hand — and from forgetting that offsets change with daylight saving.
The fastest way to pick a slot is visual: stack everyone's working hours on one timeline and look for the overlap.
Communicate times in UTC, written as ISO 8601 with an offset, so there is never a "your time or mine?".
Pin recurring meetings to a named zone like Europe/London, not a fixed UTC time, so they follow daylight-saving shifts.
Time-zone drift breaks scheduled jobs the same way it breaks meetings.

Why scheduling across time zones goes wrong

The trap is assuming the gap between two cities is a fixed number. It is not. London and New York are five hours apart for most of the year — but for roughly two weeks each spring and autumn, when one region has changed its clocks and the other has not, the gap is four hours. Every "always five hours apart" rule of thumb is wrong twice a year.

Three things compound it:

Bare local times. "3pm" carries no zone. The moment it leaves your calendar and lands in an email, half the recipients silently assume it means their 3pm.
The date line. When it is 9am Monday in California, it is already 2am Tuesday in Sydney. Mental arithmetic that ignores the day rollover books people for the wrong date, not just the wrong hour.
The wrong canonical reference. Teams store "the meeting time" as whatever the organiser's clock said, so when the organiser travels or their region shifts, the stored time moves with them.

Get those three straight and the rest is mechanical. Ignore them and you generate a steady trickle of missed calls that everyone blames on "time zones" rather than on arithmetic.

How to find a meeting time that works in every time zone

Stop converting in your head. The reliable method is visual: take each participant's working hours — say 09:00 to 17:00 local — translate them onto one shared axis, and look for the column where the bands overlap.

Worked example. A call between London, New York, and São Paulo:

London (UTC+1 in summer): 09:00–17:00 local is 08:00–16:00 UTC.
New York (UTC−4): 09:00–17:00 local is 13:00–21:00 UTC.
São Paulo (UTC−3): 09:00–17:00 local is 12:00–20:00 UTC.

The only window all three share is 13:00–16:00 UTC — early afternoon in London, mid-morning in New York and São Paulo. Any slot in that band is inside everyone's working day.

src="/blog/figures/timezones-overlap.jpg"
alt="Three stacked 24-hour timelines for London, New York and São Paulo with each city's nine-to-five band shaded, and the 13:00 to 16:00 UTC overlap highlighted"
caption="Stack each city's working hours on one UTC axis and the shared window is obvious — here, 13:00–16:00 UTC."
/>

Rather than work that out by hand, drop each city onto the timeline and read the overlap straight off the grid. When the zones are far enough apart that no band overlaps — San Francisco and Sydney, classically — there is no good answer, only a least-bad one. Seeing that on screen is the point: it tells you to rotate the awkward slot between teams instead of always burdening the same people.

Anchor on whoever has the narrowest availability. If one person observes a school run or a hard 18:00 stop, their constraint defines the window — fit everyone else around it rather than finding a slot that suits the majority and quietly excludes them.

Store and share times in UTC and ISO 8601

Pick one canonical reference for every stored timestamp, and make it UTC. Convert to local only at the moment you display it. That single rule removes a whole category of bug, because the stored value never depends on where anyone happens to be sitting.

When you write a time down for a human, use ISO 8601 with an explicit offset: 2026-06-10T15:00:00+01:00. It is unambiguous, sorts correctly as text, and every calendar app parses it.

src="/blog/figures/timezones-date-terminal.jpg"
alt="A terminal rendering one UTC instant, 14:00 UTC, in London, New York and Sydney using the date command with the TZ variable, showing 15:00 BST, 10:00 EDT and midnight the next day in Sydney"
caption="One instant in UTC, rendered in three zones — note the DST-correct abbreviations and Sydney's date rollover."
/>

For sharing, the rule is the same: never write a bare "3pm" and hope. Send the ISO timestamp, or a link that renders the slot in each person's local zone so nobody has to count. The same drift that derails meetings also derails automation — a scheduled task set in the wrong zone fires at the wrong hour — which is exactly why the cron expression helper shows fire times in a zone you choose rather than guessing the server's.

Daylight saving: the shift that breaks recurring calls

Daylight saving is where "I'll just remember the offset" finally collapses. Regions switch on different weekends, the southern hemisphere runs opposite to the northern, and places like most of Arizona or the entire UTC-anchored server fleet never switch at all. The offset between any two of them is a moving target.

An offset is a fact about a moment, not a property of a city — and it changes twice a year.

The costliest version is the recurring meeting. Book a weekly call as a fixed UTC time and it will drift by an hour for half the attendees the next time a clock changes — they show up early or late for weeks until someone notices.

Pin recurring events to a named IANA zone (Europe/London, America/New_York), never to a fixed UTC offset. A calendar that knows the zone applies each daylight-saving transition automatically; one that only knows "+01:00" freezes that offset and silently shifts the call for everyone the moment the rules change.

Compare any time zones in one screen

When a call spans three or more zones, stop converting in your head and put them all on one timeline.

Skojio's timezone helper lays every zone on a single 24-hour grid, stays accurate through daylight saving by using live zone data, lets you drag the time to find a slot, and gives you a shareable link that opens in each colleague's own local time. It runs entirely in your browser — no account, no calendar permissions, nothing uploaded.

Recap

Problem	Fix
Ambiguous "3pm"	Attach a zone, or send ISO 8601 with the offset
Offset arithmetic by hand	Stack zones on one timeline and read the overlap
Recurring call drifts at DST	Pin the event to a named zone, not a fixed UTC offset
No shared working hours	Rotate the awkward slot; share a link so no one miscounts

Time zones are only hard when you do them in your head. Line the zones up on one screen, agree the slot in UTC, and share it as a link — the next "whose 3pm?" thread never gets started.

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

99.9% Uptime: How Much Downtime Is That, Really? (Plus Combined SLA)

What Does 99.9% Uptime Actually Mean?

The Nines, From One to Six

How to Convert an Outage Into an Uptime Percentage

Combined SLA for Dependent Services: Why You Can't Just Average

Comparing Vendor SLAs Side by Side

Try It Yourself

How to Generate TypeScript Types from JSON (Without Getting Optional Fields Wrong)

What "generate TypeScript types from JSON" actually means

The single-sample problem: why optional fields go missing

What correct multi-sample merging looks like

Handling JSON to TypeScript nested objects

Other details worth checking before you trust a converter's output

Try it: a json to typescript converter built around correct merging

How to Flatten Nested JSON to CSV (and Convert It Back Without Losing Data)

Why nested JSON breaks naive CSV export

Flattening nested objects: pick a separator, then be consistent

Nested arrays: the decision most tools get wrong

Custom delimiters: comma isn't universal

Going the other way: CSV to nested JSON, with real types

Round-trip fidelity: why the settings have to match on both sides

Try it: a converter built around round-trip fidelity

Chmod 755 vs 644 vs 777: What Linux File Permissions Actually Mean

How Octal Permission Numbers Work

Chmod 755 vs 644: When to Use Each

Why chmod 777 Is (Almost) Always the Wrong Answer

Symbolic Notation: What Does rwxr-xr-x Mean?

Reading Full ls -l Output

Setuid, Setgid, and the Sticky Bit — the Fourth Digit

Try It Yourself

How to decode a Base64 string (4 reliable ways)

What a Base64 string actually is (and why it's not encryption)

Decode a Base64 string in the terminal with base64 --decode

Decode Base64 in the browser console with atob

Why your Base64 string won't decode — padding, URL-safe, and UTF-8

Decode any Base64 string in one paste

Recap

What does a cron expression mean? Read it field by field

The five fields of a cron expression, left to right

How to read *, ,, -, and / in any cron field

What 0 9 * * 1-5 means in plain English (worked example)

Special strings and the optional sixth field

Read any cron expression in plain English

Recap

How to remove unused CSS and shrink your stylesheet

Why unused CSS piles up in production

How to find unused CSS in the Chrome DevTools Coverage panel

Remove unused CSS in a build with PurgeCSS (and where it falls short)

Shrink the CSS you keep — without a build pipeline

Recap

Schedule a meeting across time zones without the guesswork

Why scheduling across time zones goes wrong

How to find a meeting time that works in every time zone

Store and share times in UTC and ISO 8601

Daylight saving: the shift that breaks recurring calls

Compare any time zones in one screen

Recap

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

Decode a Base64 string in the terminal with `base64 --decode`

Decode Base64 in the browser console with `atob`

How to read `*`, `,`, `-`, and `/` in any cron field

What `0 9 * * 1-5` means in plain English (worked example)

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