Glossary

Monitoring has its own vocabulary, and it borrows freely from observability, SRE, networking and DevOps. This glossary explains the terms you'll meet across WatchFor — and across the wider reliability world — in plain language.

Monitoring & uptime

• Monitoring — continuously checking that a system behaves as expected, and raising the alarm when it doesn't. The opposite of finding out from your users.
• Uptime — the share of time a service is available and working, usually expressed as a percentage over a period (e.g. 99.95% this month).
• Downtime — the time a service is unavailable or failing its checks. Can be planned (maintenance) or unplanned (an incident).
• Availability — how reliably a service is reachable and functional. "Availability" and "uptime" are often used interchangeably.
• Nines — shorthand for availability targets by the number of nines: three nines (99.9%) allows ~43 minutes of downtime a month, four nines (99.99%) ~4 minutes, five nines (99.999%) ~26 seconds.
• Synthetic monitoring — actively probing a service from the outside with scripted requests, on a schedule, whether or not real users are present. This is what most of WatchFor's checks are.
• Real User Monitoring (RUM) — measuring experience from actual user sessions in the browser, rather than synthetic probes. Synthetic answers "is it up?"; RUM answers "how does it feel for real people?"
• Black-box monitoring — watching a system from the outside, by its external behaviour (status codes, latency), with no knowledge of its internals.
• White-box monitoring — watching a system from the inside, using metrics and signals it exposes about its own state.
• Heartbeat / cron monitoring — a "dead man's switch" for scheduled jobs: the job is expected to check in periodically, and you're alerted when it doesn't. Perfect for backups, cron jobs and pipelines.
• Check (probe) — a single execution of a monitor: one request, from one location, at one moment.
• Polling interval (frequency) — how often a monitor runs its check. Shorter intervals detect problems faster at the cost of more checks.
• Keyword / content check — asserting that a response contains (or doesn't contain) specific text — catching "200 OK but the page is broken" errors.
• Multi-location monitoring — running checks from several geographic vantage points to distinguish a real outage from a local network problem.
• Flapping — a monitor rapidly alternating between healthy and failing, often from an unstable dependency or a too-tight threshold. A common source of noise.
• False positive / false negative — an alert for a problem that isn't real (positive), or silence during a problem that is (negative). Good monitoring minimises both.
• Maintenance window — a planned period during which alerts are suppressed so expected work doesn't page anyone or dent uptime.

Observability

• Observability — how well you can understand a system's internal state from the outside. Monitoring tells you that something is wrong; observability helps you ask why without shipping new code.
• Telemetry — the data a system emits about itself — metrics, logs and traces — that powers monitoring and observability.
• Three pillars of observability — the classic grouping of telemetry into metrics, logs and traces.
• Metric — a numeric measurement over time, such as request rate, error count or latency. Cheap to store and great for dashboards and alerts.
• Log — a timestamped record of a discrete event. Rich in detail, heavier to store and search than metrics.
• Structured logging — emitting logs as machine-readable key/value data (often JSON) instead of free-form text, so they can be queried reliably.
• Trace (distributed tracing) — a record of one request's journey across all the services it touched, showing where time was spent and where it failed.
• Span — a single timed unit of work within a trace (e.g. one database call). Spans nest to form the full trace.
• OpenTelemetry (OTel) — the open, vendor-neutral standard for generating and collecting telemetry, now the de-facto way to instrument applications.
• Instrumentation — adding code (or agents) that emit telemetry, so a system can be observed.
• Cardinality — the number of unique values a label or dimension can take. High cardinality (e.g. per-user IDs) is powerful for debugging but expensive to store and query.
• Time-series — a sequence of values recorded over time. The native shape of most metrics.
• APM (Application Performance Monitoring) — tooling focused on application- level performance: transaction traces, slow queries, code-level bottlenecks.
• Golden signals — Google's four most useful service metrics to watch: latency, traffic, errors and saturation.
• eBPF — a Linux technology for safely running tracing/observability programs inside the kernel, enabling deep visibility with very low overhead.

Reliability & SRE

• SRE (Site Reliability Engineering) — a discipline that applies software engineering to operations, treating reliability as a product feature with measurable targets.
• SLI (Service Level Indicator) — the actual measured number that represents quality, e.g. "99.93% of requests succeeded".
• SLO (Service Level Objective) — the target you hold yourself to for an SLI, e.g. "99.9% success over 30 days". Your internal goal.
• SLA (Service Level Agreement) — a contractual promise to customers about a service level, usually with penalties if breached. An SLA is an SLO with legal and financial teeth.
• Error budget — the allowed amount of failure before you breach an SLO (100% minus the SLO). Spend it on shipping features; run out and you slow down and focus on reliability.
• Toil — repetitive, manual, automatable operational work that scales with the system but adds no lasting value. SRE aims to reduce it.
• Reliability — the probability that a system works correctly over time.
• Resilience — a system's ability to keep working (or recover quickly) when parts of it fail.
• Fault tolerance — designing so that the failure of a component doesn't take down the whole system.
• Redundancy — running spare or duplicate components so one failure doesn't cause an outage.
• Failover — automatically switching to a standby component when the primary fails.
• Graceful degradation — shedding non-essential functionality under stress so the core service keeps running, instead of failing completely.
• Single point of failure (SPOF) — a component whose failure alone brings down the whole system. Reliability work hunts these down.
• High availability (HA) — an architecture designed to minimise downtime, typically through redundancy and failover.
• Disaster recovery (DR) — the plan and tooling to restore service after a major failure. Measured by RTO (how fast you recover) and RPO (how much data you can afford to lose).
• Chaos engineering — deliberately injecting failures into a system to find weaknesses before they cause real outages.
• Blast radius — how much of a system an incident or change can affect. Limiting blast radius is a core reliability goal.
• Capacity planning — forecasting demand and provisioning resources so the system stays healthy under expected (and unexpected) load.

Incidents & alerting

• Incident — an unplanned disruption or degradation of a service that needs a response. In WatchFor, the lifecycle of one confirmed problem.
• Incident management (incident response) — the process of detecting, coordinating, resolving and learning from incidents.
• Alert — an automated notification that a condition needs attention. The unit of "wake someone up".
• On-call — the rotation of people responsible for responding to alerts at a given time, including outside business hours.
• Escalation policy — the rules for who gets notified, and who's notified next if the first responder doesn't acknowledge in time.
• Paging — urgently notifying an on-call responder (historically via pager, now via a paging tool like PagerDuty).
• Acknowledgment (ack) — a responder signalling "I've got this", which usually pauses further escalation.
• Severity (SEV) — how serious an incident is, often SEV1 (critical, full outage) down to SEV3/4 (minor). Drives urgency and who's involved.
• Alert fatigue — the desensitisation that sets in when people get too many alerts, causing real ones to be missed. The cardinal sin of alerting.
• Alert storm — a flood of alerts from a single underlying problem cascading across many checks.
• Deduplication (dedup) — collapsing many alerts about the same problem into one, to cut noise.
• Signal-to-noise ratio — the proportion of alerts that are actionable versus noise. High signal-to-noise keeps responders trusting the pager.
• Noise — alerts that aren't actionable. The thing every alerting strategy is trying to eliminate.
• Runbook (playbook) — a documented, step-by-step procedure for handling a known type of incident or task.
• Root cause analysis (RCA) — the investigation into the underlying cause of an incident, beyond the surface symptom.
• Postmortem (retrospective) — a written review after an incident covering what happened, why, and how to prevent recurrence.
• Blameless postmortem — a postmortem focused on systems and process, not punishing individuals — which is what makes people share honest detail.
• Incident commander (IC) — the person coordinating the response to a major incident (not necessarily the one fixing it).
• War room — the (physical or virtual) space where responders coordinate during a major incident.
• Notification channel — a destination for alerts: email, Slack, Discord, PagerDuty, a webhook, and so on.

Metrics & the math of reliability

• Latency — how long a request takes to be served. Usually reported as percentiles, not averages, because averages hide the slow tail.
• Percentiles (p50, p95, p99) — the value below which a given share of requests fall. p99 latency of 800ms means 99% of requests were faster than 800ms — and that slowest 1% is often where users feel pain.
• Tail latency — the slow end of the latency distribution (p95–p99.9). Small in count, large in user impact.
• Throughput — how much work a system handles per unit time (e.g. requests per second).
• Apdex — a 0–1 score summarising user satisfaction with response times, based on "satisfied / tolerating / frustrated" thresholds.
• MTTD (Mean Time to Detect) — the average time from when a problem starts to when it's noticed.
• MTTA (Mean Time to Acknowledge) — the average time from alert to a human taking ownership.
• MTTR (Mean Time to Recovery / Repair) — the average time to restore service after an incident begins. The headline incident-management metric.
• MTBF (Mean Time Between Failures) — the average time a system runs between failures; higher is better.
• MTTF (Mean Time to Failure) — the average lifespan of a non-repairable component before it fails.

Networking & connectivity

• DNS — the system that translates human names (example.com) into IP addresses. A frequent, and frequently overlooked, cause of outages.
• DNS propagation — the delay while a DNS change spreads across resolvers worldwide, bounded by record TTLs.
• TTL (Time To Live) — how long a DNS record (or cached item) may be reused before it must be looked up again.
• Round-trip time (RTT) — the time for a packet to travel to a host and back. The basis of ping latency.
• Packet loss — the percentage of network packets that never arrive, causing retransmissions, slowness and dropped connections.
• Jitter — variation in latency between packets. High jitter degrades calls, streaming and real-time apps even when average latency looks fine.
• Traceroute / MTR — tools that map the hop-by-hop path to a host. MTR adds continuous per-hop latency and loss, great for pinpointing a bad hop.
• TCP / UDP — the two main transport protocols: TCP is connection-oriented and reliable; UDP is connectionless and fast, used for DNS, streaming and games.
• TLS / SSL — the protocol that encrypts traffic (the "S" in HTTPS). "SSL" is the old name; modern connections use TLS, but the term SSL stuck.
• Certificate (TLS certificate) — the credential that proves a server's identity and enables encryption. Expired certificates are a classic, avoidable outage.
• CDN (Content Delivery Network) — a network of edge servers that caches content close to users for speed and resilience.
• Edge — infrastructure positioned close to end users (as opposed to a central origin), used by CDNs and edge compute.
• DDoS (Distributed Denial of Service) — an attack that overwhelms a service with traffic from many sources to take it offline.
• TTFB (Time To First Byte) — the time from a request until the first byte of the response arrives. A good proxy for backend/origin responsiveness.

Web performance

• Core Web Vitals — Google's user-centric metrics for real-world page experience: LCP, CLS and INP. They influence both UX and search ranking. WatchFor can monitor them.
• LCP (Largest Contentful Paint) — how long until the largest visible element loads. A proxy for "when does the page feel loaded?" (good: under 2.5s).
• CLS (Cumulative Layout Shift) — how much the page visually jumps around as it loads. Low is good; high is the "tap the wrong button" experience.
• INP (Interaction to Next Paint) — how quickly the page responds to user input across the whole visit. It replaced FID as a Core Web Vital in 2024.
• FID (First Input Delay) — the older responsiveness metric (delay on the first interaction), now superseded by INP.
• Lighthouse — Google's open-source tool that audits a page's performance, accessibility, SEO and best practices, producing a 0–100 score.
• Page load time — the total time for a page to finish loading. A blunt metric compared with Core Web Vitals, but still widely quoted.

DevOps, delivery & cloud

• DevOps — a culture and set of practices that merge development and operations to ship software faster and more reliably.
• DevSecOps — DevOps with security built into every stage rather than bolted on at the end ("shift security left").
• Platform engineering — building internal platforms and "paved roads" that let product teams ship safely without reinventing infrastructure each time.
• CI/CD — Continuous Integration (merging and testing changes constantly) and Continuous Delivery/Deployment (automatically releasing them).
• Infrastructure as Code (IaC) — managing infrastructure through version- controlled config files instead of manual clicks. Tools: Terraform, Pulumi.
• GitOps — using Git as the single source of truth for infrastructure and deployments, with changes applied by automation from the repo.
• Container — a lightweight, isolated package of an app and its dependencies that runs the same anywhere. Docker is the common format.
• Kubernetes (K8s) — the dominant platform for orchestrating containers across a cluster: scheduling, scaling, self-healing and networking.
• Microservices — an architecture of small, independently deployable services instead of one large application. Great for scale, harder to observe.
• Service mesh — an infrastructure layer that handles service-to-service communication (routing, retries, mTLS, telemetry) without app code changes.
• Canary deployment — releasing a change to a small slice of traffic first, watching the metrics, then rolling out wider if it's healthy.
• Blue-green deployment — running two identical environments and switching traffic from old (blue) to new (green) for instant, reversible releases.
• Feature flag — a switch that turns functionality on or off at runtime, so you can release code without exposing it, and roll back instantly.
• Rollback — reverting to a previous known-good version after a bad release.
• Autoscaling — automatically adding or removing capacity in response to load.
• Serverless — running code without managing servers, where the platform scales to demand and you pay per execution (e.g. AWS Lambda).
• DORA metrics — four research-backed measures of delivery performance: deployment frequency, lead time for changes, change failure rate, and time to restore service.
• Shift-left — moving testing, security and observability earlier in the development cycle, where issues are cheaper to fix.

Security & email reputation

• Zero trust — a security model that trusts nothing by default and verifies every request, regardless of network location.
• Vulnerability / CVE — a known security weakness; a CVE is its standardised public identifier (e.g. CVE-2024-12345).
• Data breach — an incident where data is exposed or stolen. Monitoring for exposed credentials lets you respond before attackers do.
• SPF (Sender Policy Framework) — a DNS record listing which servers may send email for your domain, helping receivers reject spoofed mail.
• DKIM (DomainKeys Identified Mail) — a cryptographic signature on outgoing mail that lets receivers verify it wasn't tampered with.
• DMARC — a policy, built on SPF and DKIM, that tells receivers what to do with mail that fails authentication — and reports back who's sending as you.
• Blacklist / RBL (Realtime Blocklist) — a list of IPs or domains known for spam or abuse. Landing on one can silently kill your email deliverability.
• Certificate expiry — the date a TLS certificate stops being valid. Past it, browsers reject your site — so it's worth alerting on weeks ahead.

Health checks, testing & safe delivery

• Health check — an endpoint or probe a service exposes to report whether it's alive and ready to serve. The building block of automated recovery.
• Liveness probe — a Kubernetes health check that restarts a container if it stops responding (is it alive?).
• Readiness probe — a Kubernetes health check that decides whether a container should receive traffic yet (is it ready?).
• Smoke test — a quick, shallow check that core functionality works after a deploy, before deeper testing.
• Synthetic transaction — a scripted, multi-step user journey (log in, search, check out) run on a schedule to catch broken flows, not just broken pages.
• Load testing — pushing expected traffic at a system to verify it performs under realistic load.
• Stress testing — pushing beyond expected limits to find the breaking point and how the system fails.
• Soak (endurance) testing — running sustained load for a long period to surface slow leaks, like memory growth.
• A/B testing — releasing two variants to different user groups to compare outcomes with real traffic.
• Dark launch — shipping a feature to production but hidden, often to test load or behaviour before exposing it.
• Progressive delivery — releasing changes gradually (canary, rings, percentages) with automated checks, rather than all at once.
• Deployment ring — a stage in a phased rollout (internal → early adopters → everyone), each a wider audience.
• Canary analysis — automatically comparing a canary's metrics against the baseline to decide whether to promote or roll back.
• Immutable infrastructure — never modifying servers in place; instead replacing them with freshly built ones, so state never drifts.
• Golden image — a pre-baked, version-controlled machine or container image used as the consistent starting point for deployments.

Resilience patterns

• Circuit breaker — a pattern that stops calling a failing dependency for a while, letting it recover instead of hammering it (and failing fast meanwhile).
• Retry — re-attempting a failed operation, ideally only for transient errors and with sensible limits.
• Exponential backoff — increasing the wait between retries (usually with random jitter) to avoid synchronised retry storms.
• Bulkhead — isolating resources (like connection pools) so a failure in one part can't sink the whole ship.
• Timeout — capping how long to wait for a response, so a slow dependency doesn't block everything indefinitely.
• Rate limiting — capping how many requests a client can make in a window, to protect a service from overload or abuse.
• Throttling — deliberately slowing or rejecting work when a system is near capacity.
• Backpressure — a downstream component signalling upstream to slow down when it can't keep up.
• Load shedding — intentionally dropping low-priority work under extreme load to keep the core service alive.
• Idempotency — designing an operation so doing it twice has the same effect as once — essential for safe retries.
• Debounce — collapsing rapid repeated events into a single action after things settle, to avoid thrashing.
• Dead-letter queue (DLQ) — a holding area for messages that repeatedly fail processing, so they don't block the queue and can be inspected later.
• Graceful shutdown (draining) — letting a service finish in-flight work and stop taking new requests before it exits, avoiding dropped requests.
• Failback — returning to the primary system after a failover, once it's healthy again.

Kubernetes & cloud-native

• Pod — the smallest deployable unit in Kubernetes: one or more containers that share network and storage.
• Node — a worker machine (virtual or physical) in a Kubernetes cluster that runs pods.
• Namespace — a virtual partition within a cluster for isolating and organising resources.
• Ingress — the rules and controller that route external HTTP(S) traffic to services inside a cluster.
• Sidecar — a helper container running alongside the main one in a pod, adding capabilities like proxying or telemetry.
• Operator — software that encodes operational know-how to manage a complex app on Kubernetes automatically.
• Helm — the de-facto package manager for Kubernetes, templating and versioning deployments as "charts".
• DaemonSet — a Kubernetes object that runs one copy of a pod on every node (used for agents and collectors).
• Horizontal Pod Autoscaler (HPA) — scales the number of pods up and down based on load metrics.
• Availability zone (AZ) — an isolated datacentre within a cloud region; spreading across AZs survives a single-zone failure.
• Region — a geographic cloud location containing multiple availability zones.
• Multi-tenancy — serving many isolated customers (tenants) from shared infrastructure, with strict data separation.
• Edge compute — running code close to users at the network edge for lower latency.
• WebAssembly (WASM) — a portable, sandboxed binary format increasingly used for fast, secure edge and plugin workloads.
• Cattle vs pets — a mindset: treat servers as interchangeable "cattle" you replace, not unique "pets" you nurse back to health.
• Control plane / data plane — the "brain" that makes decisions (control) versus the part that actually carries traffic or work (data).

Data, caching & messaging

• Replication — keeping copies of data on multiple nodes for durability and read scaling.
• Sharding — splitting data across partitions so no single node holds it all, enabling horizontal scale.
• Eventual consistency — a model where replicas converge to the same value over time, trading immediacy for availability.
• Strong consistency — every read sees the latest write, at the cost of more coordination and latency.
• CAP theorem — under a network partition, a distributed system can favour consistency or availability, not both.
• Cache — a fast store of recently used data to avoid recomputing or re-fetching it.
• Cache hit ratio — the share of requests served from cache; higher means less load on the origin.
• Cache invalidation — removing or refreshing stale cached data — famously one of the genuinely hard problems in computing.
• Write-ahead log (WAL) — recording changes to a durable log before applying them, so a crash can be recovered.
• Change data capture (CDC) — streaming a database's row-level changes to other systems in near real time.
• Message queue — a buffer that decouples producers from consumers, smoothing spikes and enabling async work.
• Pub/sub — a messaging pattern where publishers broadcast events and any number of subscribers receive them.
• Event-driven architecture — building systems that react to events rather than calling each other directly.
• Stream processing — computing over continuous data in motion, rather than in periodic batches.
• Data retention — how long data is kept before it's deleted or archived, balancing usefulness against cost.
• Downsampling (rollup) — aggregating high-resolution data into coarser summaries over time to save space while keeping the trends.

Observability, deeper

• RED method — monitor a service by its Rate, Errors and Duration — a simple, request-centric starting point.
• USE method — monitor a resource by its Utilisation, Saturation and Errors — the resource-centric counterpart.
• SLO burn rate — how fast you're consuming your error budget; a high burn rate means an SLO breach is imminent.
• Error rate — the proportion of requests that fail; a primary alerting signal.
• Saturation — how "full" a resource is (CPU, memory, queue depth) — often the leading indicator of trouble.
• Sampling (head vs tail) — keeping a subset of traces to control cost: head sampling decides up front; tail sampling decides after seeing the whole trace (e.g. keep the slow ones).
• Exemplar — a link from an aggregated metric to a specific trace that exemplifies it, bridging "what" and "why".
• Continuous profiling — always-on, low-overhead profiling of running code to find CPU and memory hotspots in production.
• Flame graph — a visualisation of where a program spends time, with wider bars meaning more time.
• Log level — the severity of a log line (debug, info, warn, error), used to filter signal from detail.
• Heatmap — a chart showing the distribution of a value over time, revealing patterns an average hides.
• Trace context (propagation) — the IDs passed between services so spans can be stitched into one trace.
• OTLP — the OpenTelemetry Protocol, the standard wire format for shipping telemetry.
• Collector (agent) — a component that receives, processes and forwards telemetry from your apps to a backend.
• Push vs pull metrics — whether apps push metrics to a backend, or the backend scrapes (pulls) them on a schedule.

Networking, deeper

• Anycast — advertising one IP from many locations so users are routed to the nearest — the backbone of CDNs and resilient DNS.
• BGP — the protocol that routes traffic between networks on the internet; misconfigurations can cause global outages.
• HTTP/2 — a major HTTP revision adding multiplexing and header compression for faster loads over one connection.
• HTTP/3 (QUIC) — the latest HTTP, running over UDP-based QUIC for lower latency and better behaviour on flaky networks.
• gRPC — a high-performance RPC framework using HTTP/2 and protocol buffers, common between microservices.
• mTLS (mutual TLS) — TLS where both client and server present certificates, so services authenticate each other.
• Reverse proxy — a server in front of backends that handles routing, TLS, caching and load distribution.
• Load balancer — distributes incoming traffic across multiple servers, often skipping unhealthy ones.
• GeoDNS — returning different DNS answers based on the requester's location, to route users to the nearest region.
• DNSSEC — cryptographic signatures on DNS records that let resolvers detect tampering.
• NXDOMAIN — the DNS response for "this name does not exist" — a common symptom of a misconfigured or expired domain.
• MX record — the DNS record naming which mail servers receive email for a domain.
• CNAME — a DNS alias pointing one name at another.
• A / AAAA record — DNS records mapping a name to an IPv4 (A) or IPv6 (AAAA) address.
• TXT record — a free-form DNS record used for SPF, DKIM, domain verification and more.
• CAA record — a DNS record specifying which certificate authorities may issue certificates for a domain.

Web performance, deeper

• First Contentful Paint (FCP) — when the first piece of content appears — the first sign to a user that something is happening.
• Time to Interactive (TTI) — when a page becomes fully usable, not just visible.
• Total Blocking Time (TBT) — how long the main thread was blocked during load; a lab proxy for responsiveness.
• Speed Index — how quickly the visible page fills in, lower being better.
• Critical rendering path — the sequence of steps a browser must complete to render the initial view; optimising it speeds first paint.
• Lazy loading — deferring the loading of off-screen images and assets until they're actually needed.
• Preload / prefetch — hints that tell the browser to fetch key resources early (preload) or likely-next ones ahead of time (prefetch).
• Compression (gzip / Brotli) — shrinking text responses on the wire; Brotli usually beats gzip on ratio.

Modern, AI & cost

• AIOps — applying machine learning to operations data to spot anomalies, correlate alerts and cut noise.
• Anomaly detection — flagging values that deviate from a learned baseline, instead of relying only on fixed thresholds.
• Predictive alerting — forecasting a breach (e.g. "disk full in 3 hours") and alerting before it happens.
• LLM observability — monitoring large-language-model apps: latency, cost, token usage, quality and hallucination rates.
• ChatOps — running operations from chat tools, where alerts, runbooks and actions live where the team already talks.
• FinOps — bringing financial accountability to cloud spend, so engineering and finance optimise cost together.
• Rightsizing — matching provisioned resources to actual usage, to cut waste without hurting performance.
• Spot instance — spare cloud capacity offered cheaply but reclaimable at short notice; great for fault-tolerant work.

Security & trust, deeper

• WAF (Web Application Firewall) — filters and blocks malicious HTTP traffic (injection, bots, common exploits) before it reaches your app.
• RBAC (Role-Based Access Control) — granting permissions by role rather than to individuals, keeping access manageable.
• Least privilege — giving each user or service only the access it actually needs, and no more.
• Secrets management — securely storing and rotating credentials, keys and tokens instead of hard-coding them.
• Audit log — an immutable record of who did what and when, for security and compliance.
• SBOM (Software Bill of Materials) — an inventory of all components and dependencies in a piece of software, key to supply-chain security.
• Supply-chain security — securing the tools, dependencies and pipelines used to build software, not just the software itself.
• OWASP Top 10 — the widely-cited list of the most critical web-application security risks.

Tools & technologies

The named products and projects you'll hear about in this space. Listing a tool here isn't an endorsement — it's a map of the landscape so the names make sense.

CI/CD & automation

• Jenkins — a veteran open-source automation server for building, testing and deploying software, extensible through a huge plugin ecosystem.
• GitHub Actions — CI/CD built into GitHub, running YAML-defined workflows on events like pushes and pull requests.
• GitLab CI/CD — GitLab's integrated pipeline engine, configured with a .gitlab-ci.yml file in the repository.
• CircleCI — a cloud-first CI/CD platform known for fast, heavily parallelised pipelines.
• Argo CD — a GitOps continuous-delivery tool that syncs Kubernetes apps to the desired state declared in Git.
• Tekton — a Kubernetes-native framework for building pipelines from reusable components.
• Spinnaker — an open-source continuous-delivery platform built for multi-cloud deployments.
• Travis CI — a hosted CI service that helped popularise simple config-as-code pipelines.
• TeamCity — JetBrains' CI/CD server with strong build-chain and IDE integration.

Containers & orchestration

• Docker — the tool that popularised containers, packaging an app and its dependencies into a portable image.
• containerd — the lightweight runtime that actually runs containers beneath Docker and Kubernetes.
• Podman — a daemonless, Docker-compatible container engine that can run containers without root.
• OpenShift — Red Hat's enterprise Kubernetes distribution with added developer and security tooling.
• Nomad — HashiCorp's simple, flexible scheduler for containerised and non-containerised workloads.
• Rancher — a platform for managing multiple Kubernetes clusters from one place.

(See also Kubernetes and Helm in Kubernetes & cloud-native.)

Infrastructure as Code & configuration

• Terraform — HashiCorp's tool for provisioning infrastructure declaratively across many providers.
• OpenTofu — an open-source, community-governed fork of Terraform.
• Pulumi — infrastructure as code using real programming languages instead of a custom DSL.
• Ansible — agentless automation for configuration management and deployment, driven by YAML playbooks.
• Puppet — a mature configuration-management tool that enforces declared system state.
• Chef — configuration management that describes infrastructure as Ruby "recipes".
• CloudFormation — AWS's native IaC service for provisioning AWS resources from templates.

Cloud platforms

• AWS (Amazon Web Services) — the largest cloud provider, offering compute, storage, databases and hundreds of managed services.
• Microsoft Azure — Microsoft's cloud platform, strong in enterprise and hybrid scenarios.
• Google Cloud (GCP) — Google's cloud, known for data, Kubernetes (which it originated) and machine-learning services.
• Cloudflare — a global edge network providing CDN, DNS, DDoS protection and edge compute.
• DigitalOcean — a developer-friendly cloud focused on simplicity and predictable pricing.
• Fastly — an edge cloud and CDN focused on real-time delivery and programmable edge logic.
• Vercel — a platform for deploying frontend and full-stack web apps, focused on developer experience.

Relational databases

• PostgreSQL — a powerful, standards-compliant open-source relational database, prized for reliability and extensibility.
• MySQL — one of the most widely used open-source relational databases, common in web stacks.
• MariaDB — a community-driven fork of MySQL.
• SQLite — a tiny, serverless, file-based SQL database embedded directly into applications.
• CockroachDB — a distributed SQL database built for horizontal scale and survivability.
• Microsoft SQL Server — Microsoft's enterprise relational database.
• Oracle Database — a long-established enterprise relational database.

NoSQL & specialised data stores

• MongoDB — a popular document database storing flexible, JSON-like records.
• Redis — an in-memory data store used as a cache, message broker and database for ultra-fast access.
• Valkey — an open-source, community-driven fork of Redis.
• Memcached — a simple, high-performance in-memory cache.
• Apache Cassandra — a wide-column store built for massive scale and high write throughput.
• DynamoDB — AWS's fully managed key-value and document database with single-digit-millisecond latency.
• Elasticsearch — a distributed search and analytics engine, often used for logs and full-text search.
• ClickHouse — a column-oriented database built for fast analytical queries over huge datasets.
• InfluxDB — a database purpose-built for time-series data such as metrics.
• Neo4j — a graph database optimised for connected data and relationship queries.

Messaging & streaming

• Apache Kafka — a distributed event-streaming platform for high-throughput, durable data pipelines.
• RabbitMQ — a widely used message broker with flexible routing and queuing.
• NATS — a lightweight, high-performance messaging system for cloud-native and edge systems.
• Apache Pulsar — a messaging and streaming platform with built-in multi-tenancy and geo-replication.
• Amazon SQS — AWS's fully managed message-queue service.

Web servers, proxies & gateways

• Nginx — a high-performance web server widely used as a reverse proxy, load balancer and cache.
• Apache HTTP Server — the venerable, highly configurable web server that powered much of the early web.
• HAProxy — a fast, reliable load balancer and proxy for TCP and HTTP traffic.
• Envoy — a modern, programmable service proxy that underpins many service meshes.
• Traefik — a cloud-native edge router that auto-discovers services and handles routing and TLS.
• Caddy — a web server known for automatic HTTPS out of the box.
• Kong — an API gateway for managing, securing and observing APIs.

Service mesh tools

• Istio — a feature-rich service mesh for traffic management, mutual TLS and telemetry between services.
• Linkerd — a lightweight, security-focused service mesh for Kubernetes.
• Consul — HashiCorp's service-discovery and service-mesh tool with health checking and a key/value store.

Observability & monitoring tools

• Prometheus — the de-facto open-source metrics and alerting system in the cloud-native world, using a pull model.
• Grafana — the popular open-source tool for dashboards over metrics, logs and traces from many sources.
• Jaeger — an open-source distributed-tracing system.
• Zipkin — an early, widely used distributed-tracing system.
• Grafana Loki — a log-aggregation system designed to be cost-effective and Prometheus-like.
• Elastic Stack (ELK) — Elasticsearch, Logstash and Kibana, a popular stack for searching and visualising logs.
• Splunk — an enterprise platform for searching, monitoring and analysing machine data.
• Datadog — a SaaS observability platform unifying metrics, traces, logs and more.
• New Relic — a SaaS observability and application-performance platform.
• Sentry — error- and performance-monitoring focused on application exceptions and traces.
• Nagios — a long-standing open-source infrastructure-monitoring system.
• Zabbix — an open-source monitoring solution for networks, servers and applications.

Incident, on-call & secrets

• PagerDuty — a popular incident-response and on-call platform for alerting, escalation and coordination.
• Opsgenie — Atlassian's on-call and alerting tool.
• HashiCorp Vault — a tool for securely storing, accessing and rotating secrets.