I Built Three Free DevOps Tools: A Cron Translator, a VPC Subnet Planner and a Kubernetes YAML Checker

This site has 51 guides, and a pattern I did not expect when I started writing them: the questions that come back — in comments, in my own day work, in the middle of incidents — are usually not knowledge problems. Nobody forgets what a subnet is at 2 a.m. What they need at 2 a.m. is the arithmetic done correctly, a schedule converted without a dialect error, and a manifest checked against the ten mistakes that always slip review. Those are tool-shaped problems, not guide-shaped ones.

So instead of guide number 52, I built the tools. There is now a free tools section on this site — also in the navigation, under Tools — with three of them. Each one is the fast path for a friction the guides describe in depth, and each one links to its guide for when you want the deep path.

TL;DR: Three free tools, all running entirely in your browser — a Cron Translator (one expression in, crontab / Kubernetes CronJob / GitHub Actions / EventBridge out, with the next 10 run times in UTC and JST), an AWS VPC Subnet Planner (carve a VPC CIDR across AZs with AWS-usable host counts — a /24 is 251, not 256), and a Kubernetes YAML Checker (pass/warn/fail on :latest images, missing requests and limits, missing probes, privileged containers and more). No sign-up, nothing uploaded, no input stored.

Originally published on DevOps Enginer.

1. Cron Translator — the same schedule is four different schedules

Paste a standard five-field cron expression and the Cron Translator returns the correct form for Linux crontab, a Kubernetes CronJob, GitHub Actions on.schedule and AWS EventBridge — plus a plain-English reading of the schedule, the next 10 run times in UTC and JST side by side, and a warning wherever a platform cannot express what you wrote.

The worked example that justifies the tool's existence: 0 9 * * 1-5 — 09:00, Monday to Friday. On a Tokyo server's crontab it fires at 09:00 JST, exactly as intended. Now carry it to the other platforms unchanged:

• EventBridge rejects the shape and renumbers the days. EventBridge cron has six fields (a year field is added), requires exactly one of day-of-month or day-of-week to be ?, and counts days of the week 1–7 starting at Sunday instead of 0–6. The correct EventBridge form of the same schedule is cron(0 9 ? * 2-6 *). Copy-paste the crontab line and the rule fires on the wrong days — or never.
• GitHub Actions accepts the string and changes its meaning. on.schedule is always UTC and has no timezone setting, so your 09:00 job fires at 18:00 JST. It also enforces a minimum interval of once every 5 minutes, whatever you write.
• Kubernetes is UTC too, unless you set spec.timeZone on the CronJob (Kubernetes 1.27+) — otherwise the schedule follows the kube-controller-manager's timezone, which is UTC in almost every cluster.

And one trap that lives inside standard cron itself: when both day-of-month and day-of-week are restricted, cron runs when either matches — 0 9 1 * 1 is the 1st of the month and every Monday. EventBridge cannot express that at all; it needs two separate rules, and the translator says so instead of mistranslating it. Quartz syntax (?, L, W, #) and 6- or 7-field expressions are flagged as unsupported, for the same reason.

The deep version of all of this is the Kubernetes Jobs and CronJobs guide — the full CronJob contract, deadlines and concurrency policies included.

2. AWS VPC Subnet Planner — a /24 is 251, and you cannot resize later

Generic subnet calculators do one subnet at a time. A VPC is a plan, so the Subnet Planner works at plan level: enter the VPC CIDR, choose a subnet size and count, set how many availability zones to spread across, and it carves the block up — every subnet's CIDR, network address, first usable, last usable, broadcast, total addresses and AWS-usable hosts, plus the leftover free space decomposed into clean CIDR blocks for the tiers you have not built yet.

The number everyone gets wrong once: a /24 has 251 usable addresses, not 256. AWS reserves five addresses in every subnet — .0 the network address, .1 the VPC router, .2 the DNS server, .3 reserved for future use, and .255 the broadcast address. That is also why the first usable address in an AWS subnet is .4, and why a /28 — the smallest subnet AWS allows — gives you 11 usable hosts, not 16.

The reason a planner earns its keep is permanence. A VPC's primary CIDR block never changes, and a subnet's CIDR is fixed at creation; you can bolt on secondary blocks later, but the original layout is the one you live with. Two minutes of carving before you create anything beats discovering at subnet nine that the block does not divide the way the whiteboard said it did.

The design reasoning behind a layout — tiers, route tables, NAT economics — is in the AWS VPC guide.

3. Kubernetes YAML Checker — valid YAML, broken production

Most manifests that fail in production were syntactically valid when they shipped. The YAML Checker pastes or uploads a manifest and reports in two layers: YAML syntax errors with line numbers, then, per document, pass/warn/fail on the production-readiness mistakes that pass kubectl apply and page you later:

• Image pinning — :latest, and untagged images, which Kubernetes treats as :latest (an untagged reference also defaults imagePullPolicy to Always, so a restart can pull different code than the one you tested).
• Missing CPU/memory requests — the scheduler's contract; without them, placement and autoscaling math are fiction.
• Missing limits — the cgroup ceiling; without them, one container starves its neighbours.
• Missing liveness and readiness probes.
• privileged: true, runAsUser: 0, and runAsNonRoot not set — worded honestly: "not set" does not prove the container runs as root, it means the manifest guarantees nothing and the image decides.
• hostNetwork / hostPID / hostIPC, a missing namespace (how a test Deployment ends up in the production namespace), missing labels, and a missing container securityContext. Pod specs inside Deployments, Jobs and CronJobs are all checked.

Two honest framings, printed on the tool page too. First: this is a common-mistakes checker, not a schema validator. It does not run the Kubernetes OpenAPI schema, so it cannot catch every misspelled field — the authoritative check remains kubectl apply --dry-run=server, which asks the API server itself. Second: your manifest never leaves your machine. The checker is client-side JavaScript; nothing is uploaded, logged or stored, which is why it is safe to paste real manifests. Still redact live Secret values before pasting them into any online tool — redacted examples check exactly the same way.

For the configuration side of the same discipline, see the Kubernetes ConfigMaps and Secrets guide and the Requests and Limits guide.

Why free, and why in the browser

Free is the short answer; the longer one is that these tools are the front door, not the shop. This site earns from the work around them — the guides' audience, and products like the Backup Verification Kit — so the tools themselves carry no price, no account wall and no trial clock.

Browser-only is a design decision, not a shortcut. A subnet plan and a production manifest are exactly the kind of input you should not have to send to a stranger's server to get arithmetic done. There is no server side to these tools: open the page, paste, close the tab, and nothing about your input exists anywhere. If a tool like this ever asks you to upload your manifests to its cloud, that is the moment to close the tab.

The honest limits

• Cron Translator: standard 5-field expressions and the common @daily/@weekly-style descriptors. Quartz extensions and 6/7-field expressions are flagged, not translated. Scheduled GitHub Actions runs can also be delayed under load — no translator can promise you the minute, only the meaning.
• Subnet Planner: IPv4 and AWS rules — VPC and subnet prefixes between /16 and /28. It carves one tier at a time; for a three-tier layout, split the VPC into per-tier blocks first (the VPC guide walks that layout), then plan each tier.
• YAML Checker: a production-readiness lint, not a validator (above). It checks Pod, Deployment, Job and CronJob pod specs; it does not know your cluster's admission policies, and passing it does not mean a manifest is right — only that the usual suspects are absent.

FAQ

Are the tools really free? Do I need an account?
Yes — free, no account, no sign-up. All three run in your browser; there is nothing to install and nothing to log in to.

Is my schedule, CIDR plan or YAML sent to a server?
No. All three tools are client-side. Your input is never uploaded, logged or stored — close the tab and it is gone.

What is the EventBridge cron expression for 9 AM on weekdays?
cron(0 9 ? * 2-6 *) — six fields, ? in day-of-month, and weekday numbers shifted by one because EventBridge counts 1 as Sunday where standard cron counts 0 (or 7). It also runs in UTC, like GitHub Actions.

How many usable IP addresses does an AWS /24 subnet have?

1. A /24 holds 256 addresses and AWS reserves five in every subnet: network, VPC router, DNS server, one for future use, and broadcast.

Does the YAML checker replace kubectl apply --dry-run=server?
No. The checker catches common production-readiness mistakes — image pinning, requests, limits, probes, privilege. The server dry-run is the authoritative schema validation. Use both: the checker in the editor, the dry-run in CI.

Can I paste a real production manifest into the checker?
The manifest never leaves your machine, so the check itself is safe. Redact live Secret values first anyway — no online tool needs them, and redacted manifests check identically.

A closing question

These three tools exist because the same frictions kept recurring. So: what small DevOps task do you still do by hand, badly, once a week? A conversion you re-derive, a checklist you re-type, arithmetic you re-check three times. Tell me in the comments — that is precisely where tool number four will come from.