A surprising amount of DevOps work starts with a small question. Is this database version still supported? Does this cron expression run when I think it does? What did that webhook actually send? Is the network having a bad day, or is it just our application?
You can search for the answer every time. A few good bookmarks make the repetitive parts quicker.
These twelve sites cover different parts of the job: learning a concept, checking a configuration, inspecting data, finding a package, or investigating an incident. DevOps Daily comes first because it covers the most ground. The rest earn their place by doing a specific job well.
The sites and features below were checked in October 2026. Each has something useful available for free; that does not mean every feature is free or unlimited.
1. DevOps Daily
Best for: engineers who want practical reading, interactive practice, and useful browser tools in one place.
DevOps Daily covers Docker, Kubernetes, Terraform, Git, Linux, CI/CD, networking, and the work around them. Alongside the articles, it has guides, exercises, quizzes, checklists, and more than 60 games and simulators.
The interactive material is the reason to bookmark it. A written explanation of Kubernetes scheduling makes more sense when you can place pods on nodes and see resource constraints affect the result. The same applies to DNS resolution, load balancing, queues, caching, and deployment pipelines.
What stands out:
- Simulators for exploring how systems behave, including terminal practice and incident scenarios.
- Exercises that walk through tasks such as configuring a reverse proxy or troubleshooting Linux performance.
- Quizzes for finding gaps in your understanding before an interview or an unfamiliar project.
- Browser tools for tasks such as checking a CIDR block, reading a cron expression, or decoding a JWT.
- A newsletter if you prefer new material delivered to your inbox.
Try it for: the concept you can describe in an interview but still hesitate to debug. Spend ten minutes with the relevant simulator, then use an exercise to apply it.
Drawbacks: it is a resource library rather than one prescribed course. A simulator also simplifies the real system; follow up with an actual environment when you need operational experience.
2. endoflife.date
Best for: checking whether the software you run is approaching the end of support.
endoflife.date collects release and support timelines for operating systems, programming languages, databases, and infrastructure tools. It saves you from hunting through several release-policy pages just to plan an upgrade.
What stands out:
- Consistent tables across projects with very different release policies.
- Support milestones and release information in one place.
- Links back to the upstream sources behind the dates.
Try it for: your next upgrade-planning session. Check the runtimes, database versions, and operating systems in the ticket before deciding which change can wait another quarter.
Drawbacks: support is not always a single date. Extended support, commercial contracts, and distribution backports can change what applies to your deployment. Follow the linked vendor policy before making a production decision.
3. Crontab.guru
Best for: checking a cron expression before you schedule something expensive or important.
Crontab.guru is a small editor that translates cron schedules into readable language. Paste an expression, change a field, and check whether the explanation matches your intention.
For example:
0 9 * * 1-5
That schedules a job at 09:00 on weekdays in the scheduler's time zone. The last part matters as much as the expression.
What stands out: a focused interface, quick feedback, and a collection of examples for common schedules.
Drawbacks: five-field cron is not universal. Quartz, cloud schedulers, and other systems add fields or change the rules. Confirm the target scheduler's syntax, time zone, and daylight-saving behavior separately.
4. CyberChef
Best for: answering “what is this data?” without writing a throwaway script.
CyberChef lets you build a recipe from operations such as decoding, decompression, hashing, and text conversion. The output of one operation becomes the input to the next.
Try it for: a test payload that was URL-encoded, then Base64-encoded. Put the decoding steps in a recipe and inspect the result after each operation. That is easier to debug than a growing chain of shell commands.
What stands out: recipes are reusable, processing runs in the browser, and the open-source project can also be run locally.
Drawbacks: a recipe link can include the input as well as the operations. Inspect what you are sharing, and use synthetic data in examples. Being able to decode a value also says nothing about whether its contents are trustworthy.
5. Qualys SSL Labs
Best for: checking what an external client sees when it connects to your HTTPS endpoint.
The SSL Labs Server Test examines public TLS services. It reports certificate-chain issues, protocol support, cipher configuration, and compatibility details.
Try it for: the morning after changing your ingress controller, reverse proxy, or certificate configuration. The certificate file on disk may be correct while the server still presents an incomplete chain.
What stands out: a detailed external assessment that goes well beyond checking a certificate's expiration date.
Drawbacks: the service needs a publicly reachable endpoint. It cannot assess a private service behind your VPN. An excellent TLS grade also does not tell you whether application authentication or authorization is correct.
6. Webhook.site
Best for: finding out what a webhook sender actually delivers.
Webhook.site gives you a URL to receive requests and an interface for inspecting them. Point a test integration at it and look at the method, headers, query parameters, and body.
A synthetic test is enough to get started:
curl -X POST 'https://webhook.site/YOUR-UNIQUE-ID' \
-H 'Content-Type: application/json' \
-H 'X-Test-Event: deployment.finished' \
-d '{"environment":"demo","status":"success"}'
Replace the placeholder with the unique URL the site gives you.
What stands out: it separates two debugging questions: did the sender make the request, and can your application handle it?
Drawbacks: anonymous URLs have request and expiration limits, and access is tied to possession of the URL. Use test events rather than production secrets or customer payloads. Receiving a signature header does not prove that the signature validates.
7. regex101
Best for: understanding why a regular expression matches too much, too little, or nothing at all.
regex101 shows matches and capture groups as you edit, with explanations of the pattern. It supports several engine flavors, including JavaScript, Python, Go, and PCRE2.
Try it for: a log parser. Add a few valid lines, a malformed line, and a line that should never match. Build the pattern against all of them rather than polishing it around one convenient example.
What stands out: immediate feedback, visible capture groups, substitutions, and explanations that make unfamiliar syntax easier to review.
Drawbacks: choose the engine used by the target application. A pattern that works in PCRE2 may fail in Go or behave differently elsewhere. Keep the final test cases in your codebase so the parser stays correct after the browser tab closes.
8. JSON Crack
Best for: getting your bearings in a deeply nested response or configuration file.
JSON Crack turns structured data into interactive graphs. It supports JSON, YAML, CSV, and XML, with formatting and conversion tools alongside the visual view.
Try it for: a sanitized API response with several layers of arrays and objects. A graph can make the relationship between deployments, environments, and resource identifiers easier to follow than repeated folding and unfolding in an editor.
What stands out: a different view of the same data, plus image exports when you need to explain its shape to someone else.
Drawbacks: very large documents become very large graphs. Reduce the input to the relevant section first. A clear graph also does not validate the meaning of the configuration or replace a schema check.
9. Mermaid Live Editor
Best for: making a quick diagram whose source can stay with the documentation.
Mermaid Live Editor previews diagrams written as text. You can use it to sketch a request path, deployment flow, or sequence of events before adding the source to a README or runbook.
For a simple request path, start with:
flowchart LR
client[Client] --> proxy[Reverse proxy]
proxy --> app[Application]
app --> database[(Database)]
What stands out: the source is easy to review in Git, and changing a label does not require reopening a drawing application.
Drawbacks: a diagram that renders in the latest editor may use syntax an older renderer does not understand. Check it in the place where readers will see it. Complex layouts can also take more effort than the text format initially suggests.
10. Artifact Hub
Best for: finding cloud-native packages and checking their details before installation.
Artifact Hub catalogs Helm charts and other artifacts, including policies, plugins, and operators. Its documentation lists the supported package types.
Try it for: comparing charts for a service you are about to deploy. Read the defaults, repository links, version history, and available security information before copying an install command.
What stands out: package discovery and metadata in one place, with links to the material you need for a closer review.
Drawbacks: discovery is the start of the decision. A verified publisher badge is not a security audit, and a recent chart release does not guarantee sensible defaults. Inspect the rendered manifests and image versions before installation.
11. OpenSSF Scorecard
Best for: getting an initial view of an open-source project's security practices.
OpenSSF Scorecard checks repository practices such as dependency pinning, workflow permissions, code review, and release controls. Its repository documents the checks and ways to run them.
Try it for: a GitHub Action or infrastructure dependency you are considering adding to CI. Read the individual check results and their explanations, then investigate the findings that matter for the access you plan to give it.
What stands out: it turns vague questions about maintenance and repository hygiene into specific things you can inspect. You can also use it through the CLI or GitHub Actions for repeatable checks.
Drawbacks: it assesses signals about a project's practices. It does not prove the code is safe or that its behavior fits your threat model. Check the age of any published results, and avoid reducing the decision to one number.
12. Cloudflare Radar
Best for: adding Internet-wide context to a network incident.
Cloudflare Radar shows traffic trends, outages, and protocol signals observed through Cloudflare's network. It can help you investigate whether a disruption appears to extend beyond your own service.
Try it for: an incident affecting users in one country while your own service metrics look normal. Compare the region and time window with Radar's outage and traffic views, then follow up with your own probes and provider status information.
What stands out: an external perspective that an application dashboard cannot supply.
Drawbacks: it reflects Cloudflare's observations and coverage. A quiet Radar view does not rule out a local ISP, route, DNS, or application problem. Treat it as another piece of evidence.
Wrapping up
A useful bookmark saves you a search or gives you a better way to inspect a problem. DevOps Daily is the broadest starting point here because you can move from an explanation to a simulator, an exercise, or a small utility. The other sites help with the specific questions that come up around that work.
Pick one you can use on your next ticket. If you want a quick starting point, open a DevOps Daily simulator for something in your current stack and see which assumptions hold up when you change the inputs.
Which website has earned a permanent place in your bookmark bar? Tell me in the comments.
Top comments (0)