--- title: Glossary description: Every term WatchFor uses — Down vs. Degraded, confirmation, incidents, escalations, MCP, A2A, JSONPath, TLS grade — plus the wider monitoring vocabulary. canonical: https://watchfor.io/docs/reference/glossary --- # Glossary Every term WatchFor uses — Down vs. Degraded, confirmation, incidents, escalations, MCP, A2A, JSONPath, TLS grade — plus the wider monitoring vocabulary. 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. The first section defines the words exactly as WatchFor uses them — these are the meanings behind every status, setting and API field. The rest is the wider reliability vocabulary you'll meet in the docs and in the industry. ## WatchFor vocabulary - **Monitor** — the thing you configure: a target (URL, host, domain, MCP server, cron job…), a monitor type, an interval, locations and options. 25 types exist; see [Monitors](/docs/monitors). - **Check** — one execution of a monitor: one request, from one [location](/docs/reference/probe-locations), at one moment. A monitor produces many checks; each records success or failure plus metrics. - **Check success** — the share of checks where the probe **reached the target and got a response**. A reachability and flakiness signal, not a health signal: a response that then fails a rule (wrong status code, failed API assertion, expired certificate) counts as reached here and surfaces as an incident instead, so a monitor can be Down at 100% check success. For health, read [uptime](/docs/monitors#how-uptime-is-calculated). - **Location (probe)** — one of WatchFor's 20 checking locations in 7 regions. "Probe" is also used for the machine that runs the check. - **Up** — the monitor's last checks succeeded. - **Degraded** — a check failed from **one** location but the failure has not been confirmed elsewhere (nothing is paged; the monitor is watched more closely) — or a confirmed incident of *warning* severity is open. - **Down** — a *critical* failure **confirmed** from several locations: an incident is open and the on-call chain is paged. Down is never declared from a single check. - **Confirmation** — the step between a failed check and an incident: WatchFor re-checks from other locations, and only opens an incident when they agree. A few monitor types skip confirmation because their answer doesn't depend on the vantage point (domain expiry, data breach, blocklist, MCP and Core Web Vitals audits) — see [How incidents work](/docs/alerting/incidents). - **Paused** — checks are stopped by you; no incidents, nothing counted. - **Alert rule** — a condition on a monitor's metrics (status code, response time, days to expiry, JSON assertion…) with a **severity**; created from presets. When it matches and is confirmed, an incident opens. - **Severity** — the importance of a rule and of the incidents it opens: **critical** (the monitor shows Down; pages on-call) or **warning** (the monitor shows Degraded; channels are notified). Used to route notifications and to decide what counts as downtime. See [Alerting](/docs/alerting). - **Incident** — a confirmed problem with a lifecycle **firing → acknowledged → resolved**, a root-cause breakdown, a timeline, internal notes and, optionally, a post-mortem. - **Acknowledge** — a team member takes ownership of an incident; escalation stops. - **Resolve** — the incident is closed, automatically when checks recover or [manually](/docs/alerting/resolving) by an owner or admin. - **Mark as maintenance** — reclassify an incident that happened during planned work so it doesn't count as downtime. - **Notification channel** — a destination for alerts: email, Slack, Discord, Telegram, Microsoft Teams, PagerDuty, Opsgenie, webhooks, SMS and [more](/docs/notifications). - **Contact / contact group** — a person (email, phone) and named groups of them; channels notify groups. - **Mute** — silence a monitor's notifications for a set time (1 hour to 7 days) while checks keep running. - **Repeat reminder** — a notification re-sent at an interval while an incident stays firing and unacknowledged. - **On-call schedule** — who is responsible when, built from **layers** (a base rotation plus optional time-restricted layers for business hours or follow-the-sun) and one-off **overrides**. See [On-call](/docs/alerting/on-call). - **Escalation policy** — the ordered steps taken when an incident opens: notify the on-call person, then escalate to the next step if nobody acknowledges within the step's timeout. - **Maintenance window** — a planned period (one-off or recurring) during which alerts are suppressed and the time is excluded from uptime, while checks keep running; can announce itself on a status page. See [Maintenance windows](/docs/monitors/maintenance). - **Run check now** — dispatch one extra check immediately, outside the schedule (owners and admins); each plan includes an hourly budget per monitor. - **Heartbeat monitor** — a monitor that expects your job to call a ping URL on an interval ("every 5 minutes") or a **cron schedule** ("03:00 daily"), and alerts when the ping doesn't arrive. See [Heartbeats](/docs/monitors/heartbeat). - **Grace period** — how late a heartbeat ping may arrive before the job is considered missed. - **Assertion** — a rule an [API monitor](/docs/monitors/api) applies to the response: a **JSONPath** expression on the JSON body, a header, or the response text. The status code is checked by its own alert rule, not by an assertion. - **JSONPath** — a query language for JSON (`$.data.items[0].status`); used by API monitors to assert on and extract values from a response, and in the [JSON formatter](/json-formatter) tool. - **Core Web Vitals** — Google's page-experience metrics (LCP, CLS, INP) measured in a real browser by the browser monitor; see the [performance monitors](/docs/monitors/performance). - **TLS grade** — an A+ to F score of a server's TLS configuration (protocols, ciphers, forward secrecy, post-quantum readiness, HSTS, certificate) from the [SSL/TLS Grade tool](/ssl-grade-checker), also available as an option on SSL monitors on plans that include it. - **Tags** — free-form labels on monitors, used to filter, bulk-edit, scope reports and back status-page components. See [Tags](/docs/monitors/tags). - **Status page** — a public (or password-protected or private) page at `yourname.watchfor.io` built from **components** — each backed by monitors or by a **third-party component** mirroring another provider's status page — with incident **announcements**, maintenance notices, uptime history, RSS, a badge and a JSON endpoint. See [Status pages](/docs/status-pages). - **Post-mortem** — the written review of an incident (what happened, why, action items), optionally published to the status page. See [Post-mortems](/docs/alerting/postmortems). - **Report** — the weekly/monthly document of uptime, incidents, MTTR/MTBF and trends compared with the previous period. See [Reports](/docs/reports). - **Activity log** — the per-organization audit trail of who changed what. See [Activity log](/docs/organization/activity-log). - **Organization (workspace)** — the tenant that owns monitors, incidents, status pages, members and billing. Members have a **role**: owner, admin or member. See [Members & roles](/docs/organization). - **API key** — a `wf_live_…` credential for the REST API, SDKs, CLI and hand-configured MCP clients, with a `read` or `write` **scope**. See [Authentication](/docs/api/authentication). - **OAuth 2.1** — the authorization flow MCP clients use to connect on a user's behalf, via a consent screen, instead of a pasted key. - **MCP (Model Context Protocol)** — the open protocol AI assistants use to call tools. WatchFor both **monitors** MCP servers (the MCP monitor type) and **is** one: the [WatchFor MCP server](/docs/api/mcp) exposes 45 tools over your organization. - **A2A (Agent2Agent)** — the open protocol for one AI agent to delegate a task to another AI agent. WatchFor's [A2A server](/docs/api/a2a) publishes 16 skills (check status, diagnose incidents, create monitors…). - **SDK / CLI** — the `watchfor` packages on npm, PyPI and RubyGems that wrap the REST API, plus the command-line tool. See the [API overview](/docs/api). - **Sandbox** — keyless, read-only sample data at `/api/v1/sandbox/*` for trying the API shapes before you have a key. - **WatchForBot** — the identity every HTTP check carries (User-Agent, reverse DNS under `*.probe.watchfor.io`, and RFC 9421 **Web Bot Auth** request signatures). See [Probe locations](/docs/reference/probe-locations). - **Free tools** — 33 one-off checkers and calculators that need no account. See [Free tools](/docs/tools). ## 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. See the [heartbeat monitor](/docs/monitors/heartbeat). - **Check (probe)** — a single execution of a monitor: one request, from one location, at one moment. In WatchFor, one failed check makes a monitor *Degraded*; only a confirmed failure makes it *Down*. - **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 and the time is excluded from uptime, so expected work doesn't page anyone or dent your numbers. In WatchFor, checks keep running during a window. ## 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 collectors) 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. See [On-call & escalations](/docs/alerting/on-call). - **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. WatchFor has [built-in post-mortems](/docs/alerting/postmortems). - **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](/docs/monitors/performance). - **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, which is what the [SSL / TLS monitor](/docs/monitors/certificates) does. - **Post-quantum cryptography (PQC)** — key-exchange algorithms designed to resist quantum computers (e.g. hybrid X25519 + ML-KEM in TLS). The [TLS grade](/ssl-grade-checker) reports whether a server offers it. - **HSTS (HTTP Strict Transport Security)** — a response header telling browsers to only ever use HTTPS for a site; part of a good TLS grade. - **Forward secrecy** — key exchange (ECDHE) that keeps past sessions safe even if the server's long-term key later leaks. ## 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 log shippers 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** — 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](#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** — automation for configuration management and deployment, driven by YAML playbooks, with nothing to install on the managed hosts. - **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. - **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. - **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. - **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. ### AI agent protocols - **MCP (Model Context Protocol)** — the open standard through which AI assistants discover and call tools; servers expose tools, resources and prompts over Streamable HTTP or stdio. - **A2A (Agent2Agent)** — the open protocol for delegation between AI agents: an A2A server publishes an *agent card* of skills that AI agents call. - **Agent card** — the machine-readable description of an A2A server, served at `/.well-known/agent-card.json`. - **OpenAPI** — the machine-readable description of a REST API; WatchFor's is at `/openapi.json`. > **Missing a term?** > > This glossary grows over time. If there's a term you'd expect to find here, > let us know — and see [Core concepts](/docs/core-concepts) for how the > WatchFor pieces fit together. --- Canonical page: https://watchfor.io/docs/reference/glossary · All docs: https://watchfor.io/docs · Site guide: https://watchfor.io/llms.txt