Monitoring & DevOps Glossary

Alert fatigue

Alert fatigue is what happens when responders receive so many alerts, most of them false or unimportant, that they stop reacting quickly to any of them. The real incident gets the same slow response as the hundred false ones before it.

Availability

Availability is the share of time a service can actually be used, expressed as a percentage. It is calculated as (total time - downtime) / total time, or from failure rates as MTBF / (MTBF + MTTR).

Auto-Scaling

The automatic adjustment of compute resources based on current demand to maintain performance and control costs.

Apdex Score

A standardized metric that rates user satisfaction with application response time on a scale from 0 to 1.

API monitoring

API monitoring checks from outside your infrastructure that API endpoints answer, answer correctly, and answer in time. A monitor sends the same request your clients send, on a schedule, and alerts when the status code, the response body, or the response time is wrong.

Alert routing

Alert routing decides where each alert goes: which person, team, or channel receives it, based on the service that failed, how urgent it is, and the time of day. Good routing sends each alert to the one person who should act on it.

Agent-based monitoring

Agent-based monitoring installs a small program, the agent, on each machine to read local metrics and send them to a monitoring service. It reaches data no outside probe can see, such as memory and disk space, at the cost of software to install and maintain on every host.

Blue-Green Deployment

A deployment strategy using two identical production environments, where traffic is switched from the current (blue) to the new (green) version.

Black-box monitoring

Black-box monitoring tests a system from the outside, the way a user reaches it, with no access to its internals. It answers one question: is the service working for users right now?

Blameless Postmortem

An incident review process that focuses on systemic improvements rather than individual fault.

Cron job

A cron job is a command or script that runs automatically on a schedule on Unix-like systems, defined by a cron expression of five fields: minute, hour, day of month, month, and day of week. For example, 0 2 * * * runs every day at 2:00.

Canary Deployment

A deployment strategy that rolls out changes to a small subset of users before a full release to detect issues early.

CPU utilization

CPU utilization is the share of time a processor spends doing work rather than sitting idle, as a percentage. It is broken down into states, such as user, system, and iowait, and reported for all cores together and for each core.

Downtime

Downtime is any period when a service is unavailable or not working correctly for its users. It is planned when announced in advance for maintenance, and unplanned when caused by a failure, a bad deploy, or an attack.

DORA Metrics

Four key metrics identified by the DORA team for measuring software delivery performance: deployment frequency, lead time, change failure rate, and MTTR.

DNS monitoring

DNS monitoring queries your DNS records on a schedule and alerts you when a record stops resolving, resolves to the wrong value, or answers too slowly. It catches failures that leave your servers running but unreachable.

Disk I/O

Disk I/O is the read and write activity between the operating system and its storage devices, measured in bytes per second and in operations per second (IOPS) for each device.

Escalation policy

An escalation policy is the ordered list of steps that decides who is alerted about an incident, through which channel, and after how long. If nobody acknowledges or fixes the problem, the alert moves to the next step: a chat message, then a text, then a phone call, then a second person.

Error budget

An error budget is the amount of failure a service is allowed before it misses its SLO. A 99.9% SLO over 30 days gives an error budget of 0.1%, about 43 minutes of downtime or 1 failed request in 1,000.

Five nines (99.999% uptime)

Five nines means 99.999% availability: no more than 5 minutes 15 seconds of downtime per year, or about 26 seconds per 30-day month. It is the target for telecom networks, payment systems, and core cloud infrastructure.

Filesystem usage

Filesystem usage is how much space is used and free on each mounted filesystem, in bytes and as a percentage of capacity. A full filesystem makes writes fail, which breaks databases, logging, and deploys.

Health check

A health check is a request that asks a service whether it can handle traffic, usually an HTTP endpoint such as /health or /healthz that returns 200 when the service is working and 503 when it isn't. Load balancers, Kubernetes, and uptime monitors call it on a schedule.

HTTP status code

An HTTP status code is the three-digit number a server returns with every response to say how the request went. Codes starting with 2 mean success, 3 a redirect, 4 a problem with the request, and 5 a problem on the server.

Host metrics

Host metrics are the resource measurements a machine reports about itself: CPU time, memory, filesystem space, disk I/O, and network traffic, plus details such as hostname, OS, and kernel. They describe the machine as a whole, not individual processes or requests.

Incident severity

Incident severity is a level, such as SEV1 to SEV4 or critical, major, and minor, that ranks an incident by its impact on users and the business. The level decides who gets paged, how fast, and whether customers are told.

I/O wait (iowait)

I/O wait, shown as iowait or wa in top and vmstat, is the share of CPU time a processor sat idle while at least one of its own disk or network I/O requests was still in flight.

Latency

The time delay between a request being sent and the response being received, typically measured in milliseconds.

Load average

Load average is the kernel's count of tasks competing for the CPU, averaged over the last 1, 5, and 15 minutes. On Linux it also counts tasks waiting on disk or network I/O, so read it against the number of CPU cores.

MTTR (mean time to recovery)

MTTR, or mean time to recovery, is the average time it takes to restore a service after a failure. Divide total downtime by the number of incidents in the same period: three outages adding up to 90 minutes give an MTTR of 30 minutes.

Maintenance window

A maintenance window is a scheduled period when a team does planned work on a system, such as an upgrade or a migration, and the service may be slow or unavailable. It is announced in advance and usually excluded from SLA calculations.

Memory utilization

Memory utilization is how much of a machine's RAM is in use. On Linux, the number to watch is available memory, the kernel's estimate of what new processes can still get, because the "used" figure includes cache the kernel frees on demand.

On-call

Being on call means being the person responsible for responding to production alerts during a set period, including nights and weekends. Teams share the duty through a rotation, so someone is always reachable and nobody carries it alone.

On-call rotation

An on-call rotation is the schedule that decides which team member is on call during each period, and the order in which the duty passes from one person to the next. A weekly rotation of five engineers puts each of them on call one week in five.

OpenTelemetry

OpenTelemetry (OTel) is an open-source CNCF project that standardizes how software produces telemetry (traces, metrics, and logs) and how it is sent to a backend, through SDKs, a collector, and the OTLP protocol.

Post-mortem (incident review)

A post-mortem is a written review of an incident after it is resolved: what happened, why, how the team responded, and what will change so it doesn't happen again. It is also called an incident review or a retrospective.

P99 Latency

The response time below which 99% of requests are served — used to measure tail latency and worst-case user experience.

RTO (Recovery Time Objective)

The maximum acceptable duration of time a service can be offline after a disaster or failure before causing unacceptable business impact.

RPO (Recovery Point Objective)

The maximum acceptable amount of data loss measured in time — how far back in time your recovery point can be.

Response time

Response time is the total time between a client sending a request and receiving the complete response. For an HTTPS request it adds up DNS lookup, TCP connection, TLS handshake, server processing, and transfer of the response.

SLA (service level agreement)

An SLA, or service level agreement, is the contract in which a provider promises a level of service, usually an uptime percentage such as 99.9% per month, and the compensation customers get when it misses. A 99.9% monthly SLA allows about 43 minutes of downtime in a 30-day month.

SLO (service level objective)

An SLO, or service level objective, is the reliability target a team sets for its own service, such as "99.95% of checks succeed over a rolling 30 days". It is internal, carries no penalty, and is usually stricter than the SLA promised to customers.

Status page

A status page is a web page where a company shows whether its services are working, posts updates during incidents, and announces scheduled maintenance. Customers check it before contacting support, and can subscribe to receive each update by email, Slack, or SMS.

Synthetic monitoring

Synthetic monitoring runs scripted checks against a website or API on a schedule, from outside your infrastructure, to confirm that key user journeys still work. A robot user logs in, searches, or checks out every few minutes, and an alert fires when a step fails.

SSL certificate

An SSL certificate, more accurately a TLS certificate, is a file that proves a server's identity and lets browsers and API clients open an encrypted HTTPS connection to it. It is issued by a certificate authority for one or more hostnames and expires on a fixed date.

SRE (Site Reliability Engineering)

A discipline that applies software engineering practices to infrastructure and operations to build scalable and reliable systems.

Server monitoring

Server monitoring collects resource metrics from the machines that run your services (CPU, memory, disk space, disk I/O, and network) and alerts when a machine is in trouble or stops reporting.

Throughput

The rate at which a system processes requests or data, typically measured in requests per second.

TCP monitoring

TCP monitoring checks that a service accepts connections on its port by opening a TCP connection to it on a schedule. It covers anything that doesn't speak HTTP: databases, mail servers, caches, game servers, and custom services.

TLS Handshake

The initial negotiation process between a client and server that establishes an encrypted HTTPS connection.

Uptime

Uptime is the share of time a service is available and working, expressed as a percentage of a period. A site that was down for 43 minutes in a 30-day month had 99.9% uptime.

Uptime SLA

The specific uptime percentage guaranteed in a service level agreement, defining maximum allowable downtime.

Webhook

A webhook is an HTTP request one application sends to a URL you choose when an event happens, carrying the event's details in a JSON body. Instead of asking an API for updates every few seconds, your system gets notified the moment something changes.

White-Box Monitoring

Monitoring based on internal system metrics, logs, and traces that reveal the internal state and behavior of a service.