Glossary

Plain explanations of the terms you will hear in software teams, from Git commands to incident reviews. Filter by any word in a term or its explanation, or narrow the list to one category. Each term has its own link, so you can point a colleague straight to it.

Filter terms

Operating Systems and Shell
Source Control
Development
Process and Agile
Quality
Data, Architecture, and APIs
Infrastructure and Cloud
Security
Operations

Operating Systems and ShellBack to top

Bash#: The most common shell on Linux, and the default on many systems. It is used both interactively and for shell scripts, with pipes, redirects and variables. Most tutorials and CI examples assume it.
chmod / chown#: Linux commands to change file permissions and ownership. chmod sets who may read, write or execute a file, for example chmod +x script.sh to make it runnable. chown changes the owning user or group.
Command Prompt (cmd)#: The classic Windows command-line shell. Its commands and batch files (.bat) are limited compared with PowerShell, but they are still common in older scripts and documentation. You will meet it in build tooling and installers.
Daemon / service#: A program that runs in the background, usually starting with the system and without a user interface. Web servers and database engines are typical examples. On Linux they are managed with tools such as systemctl, and on Windows as Services.
PATH#: An environment variable listing the folders the system searches when you type a command. If a tool is installed but the shell says command not found, its folder is probably missing from PATH. Installers often offer to add it for you.
PowerShell#: A Windows shell and scripting language that passes objects between commands instead of plain text. Commands follow a Verb-Noun pattern such as Get-ChildItem. Modern PowerShell 7 also runs on Linux and macOS.
Root / sudo#: Root is the Linux superuser account with unrestricted access to the system. The sudo command runs a single command with those rights after you confirm who you are. Use it only when needed, as a mistake with root rights can damage the system.
Shell#: A program that reads the commands you type and runs them, such as cmd, PowerShell or Bash. It also runs scripts, which are saved lists of commands. The shell is the program, while the terminal is the window that displays it.
SSH#: Secure Shell: a protocol for encrypted remote login and command execution. You normally prove who you are with a key pair instead of a password. Git hosts also use SSH keys to authenticate pushes and pulls.
Windows Terminal#: Microsoft's modern terminal app for Windows. It hosts cmd, PowerShell, Bash through WSL and other shells in tabs and panes. It supports themes, fonts and Unicode, and is the recommended place to run command-line tools on Windows.
WSL#: Windows Subsystem for Linux: a real Linux environment running inside Windows. It lets you use Bash, Linux tools and Linux-style paths without a separate machine or a full virtual machine. Many developers use it so their tools match the Linux servers they deploy to.

Source ControlBack to top

Branch#: A separate line of work that can later be merged back. Branches let you build a feature or fix a bug without disturbing the code others rely on. In Git a branch is just a movable pointer to a commit, so creating one is instant and cheap.
Cherry-pick#: Copy a single commit from one branch onto another as a new commit. It is useful for taking one fix to a release branch without merging everything else. Overusing it creates duplicate commits that make history harder to follow.
Clone#: A local copy of a remote repository, including its full history. Cloning also records where the original lives, usually under the name origin, so you can pull and push later. You clone once per machine and then keep that copy up to date.
Commit#: A saved snapshot of your changes, with a message describing what changed and why. Commits are the units of history: you can read them, compare them and undo them. Small commits with clear messages make a project much easier to understand later.
Diff#: The difference between two versions of a file, or of a whole set of files. Added lines are normally marked with a plus and removed lines with a minus. Reading diffs is the core of code review and of understanding what a commit did.
Fetch#: Download new commits and branches from the remote without touching your working files or branches. It is the safe way to see what others have done. You can then compare, merge or rebase when you are ready.
Fork#: A personal copy of someone else's repository, kept on the hosting service under your account. You use forks to propose changes to a project where you have no write access. You push to your fork, then open a pull request against the original.
HEAD#: A pointer to the commit or branch you currently have checked out. New commits are added on top of it. If HEAD points straight at a commit instead of a branch, Git calls this a detached HEAD, and commits made there are easy to lose.
main#: The default branch in most repositories, normally the stable line of work. Older projects often call it master. Teams usually protect it, so changes arrive through pull requests instead of direct pushes.
Merge#: Combining the changes from one branch into another. Git usually does this automatically and records a merge commit that ties the two histories together. When both sides changed the same lines, you get a merge conflict to resolve.
Merge conflict#: A situation where two branches changed the same part of a file and Git cannot decide which version to keep. Git marks the clashing lines in the file with conflict markers. You edit the file to the correct result, remove the markers and commit.
Pull#: Fetch remote changes and merge them into your current branch in one step. It is convenient but changes your branch immediately, which can surprise you if there are conflicts. Some people prefer to fetch first and look before they merge.
Pull request (PR)#: A request to merge one branch into another, with a place for review and discussion. Reviewers read the diff, comment and approve, and automated checks usually run on it. GitLab calls the same thing a merge request.
Push#: Upload your local commits to a remote repository so others can see them. Git rejects a push if the remote has commits you do not have, so pull or rebase first. Force-pushing overwrites remote history and should be avoided on shared branches.
Rebase#: Replay your commits on top of another branch, giving a straight, linear history. It rewrites those commits, so they get new ids. Do not rebase commits that others already use, as it forces everyone to repair their copies.
Repository (repo)#: A project folder whose history is tracked by source control. It holds your files plus the full record of every change, who made it and when. Most teams keep a shared copy on a host such as GitHub or Azure DevOps, and each developer works in a local clone.
Squash#: Combine several commits into one. Teams squash a pull request so the main branch gets one tidy commit instead of every 'fix typo' and 'try again' along the way. Squashing rewrites history, so do it on your own branch or through the merge button.
Stash#: Temporarily shelve uncommitted changes so you can switch tasks with a clean working folder. You bring them back later with git stash pop. Stashes are local and easy to forget, so do not use them as long-term storage.
Tag#: A named marker on a specific commit, most often used for releases such as v1.4.0. Unlike a branch, a tag does not move as you add commits. Tags let you find exactly what was shipped and rebuild it later.

DevelopmentBack to top

Artifact#: A file produced by a build, such as a package, a container image, a zip or an installer. Pipelines store artifacts so the exact same file can be tested and then deployed. Building once and promoting the same artifact avoids differences between environments.
Async#: Short for asynchronous: work that proceeds without blocking the caller while it waits. A common case is waiting for a network or disk response while the program does something else. Many languages offer async and await keywords to make this readable.
Boilerplate#: Repetitive code that has to be written to set something up but adds little meaning of its own. Project templates, generators and frameworks exist partly to reduce it. Too much of it hides the code that matters.
Breaking change#: A change that makes existing users or callers fail, such as removing a field from an API or renaming a function. Version numbers and release notes exist partly to warn about these. Avoid them where you can, and announce them clearly when you cannot.
Breakpoint#: A marker on a line of code where the debugger pauses execution. While paused you can inspect variable values and step through the code line by line. It is often faster and more reliable than adding print statements.
Build#: The process of turning source code into something that can run. Depending on the language this can mean compiling, bundling, downloading dependencies and running checks. A failing build means the code cannot be produced as it stands, so it is usually the first thing to fix.
Dependency#: Code written elsewhere that your project needs in order to work. Dependencies save effort but bring risks: bugs, breaking updates and security flaws come along with them. Each one you add is something you have to keep up to date.
Deprecated#: Marked as outdated: it still works for now, but you should stop using it. It will usually be removed in a later version, and the documentation normally names the replacement. Plan to move off deprecated features before they disappear.
Edge case#: An unusual input or situation at the limits of expected use, such as an empty list, a very large number or a name with an apostrophe. Many bugs live here. Thinking through edge cases while writing code and tests prevents most of them.
Exception#: An error condition raised while a program runs, which interrupts normal flow. Code can catch an exception and handle it, otherwise it travels up the call stack and may crash the program. Catch only what you can actually handle, and never swallow errors silently.
Feature flag#: A switch in configuration that turns a feature on or off without redeploying. Teams use flags to ship unfinished work safely, release to a few users first or switch a feature off fast when it misbehaves. Old flags should be removed once they are no longer needed.
Framework#: Reusable structure that decides how your application is organised and calls your code at the right moments. This inversion of control is the main difference from a library. Frameworks speed up work in the area they cover but make you follow their conventions.
Happy path#: The flow where everything works as intended: valid input, working network, no errors. It is the easiest part to build and test. A feature is only done once you have also handled the unhappy paths.
IDE#: Integrated development environment: an editor with built-in building, debugging, testing and code navigation. Visual Studio, IntelliJ and VS Code with extensions all fill this role. Learning its search, refactoring and debugging features pays off quickly.
Legacy code#: Existing code that is hard to change, often because it has no tests and nobody fully understands it. It is usually valuable, since it still runs the business. Add tests around the part you need to change before you modify it.
Library#: Reusable code that you call from your own code when you need it. You stay in control of the flow of your program and pick the functions you want. A date-handling package or an HTTP client are typical examples.
Linter#: A tool that analyses code without running it and flags style problems and likely bugs. Examples are ESLint, Pylint and Roslyn analysers. Teams run linters in the editor and in CI so the code stays consistent without arguing about style in reviews.
Null#: A value meaning 'nothing here'. Using it as if it held something causes errors such as the null reference exception. Many languages now add optional types or null checks to reduce this, and it is still wise to handle the empty case on purpose.
Package manager#: A tool that downloads, installs and updates dependencies for you. Examples are npm, pip, NuGet, Maven and apt. Most also record exact versions in a lock file so every developer and build gets the same result.
Race condition#: A bug where the result depends on the timing or order of events, such as two threads updating the same value. It may work a thousand times and then fail once, which makes it hard to reproduce. Locks, queues and avoiding shared state are the usual remedies.
Refactoring#: Restructuring code to make it clearer or easier to change, without altering what it does. Typical steps are renaming, extracting a function or removing duplication. Tests are what tell you that behaviour really stayed the same.
Regex#: Regular expression: a compact pattern language for matching and extracting text. It handles validation, search and replace, and log parsing well. Complex patterns become unreadable fast, so keep them short and comment or test them.
SDK#: Software development kit: a bundle of tools, libraries, documentation and samples for building against a platform or service. The Android SDK and the .NET SDK are well-known examples. It normally includes a compiler or build tooling and often a command-line interface.
Stack trace#: The list of function calls that led to an error, printed when a program fails. Read it to find which of your own lines was running, which is often near the top or the first frame in your code. Searching for the error message together with the key frames often leads to the cause.
Technical debt#: The future cost of shortcuts and compromises taken today. Like financial debt it accumulates interest: the longer it stays, the slower and riskier every later change becomes. Some debt is a deliberate choice, but it should be written down and repaid.
Thread#: An independent path of execution within a program. Several threads can run at once and share the same memory, which lets an app do more than one thing at a time. Shared memory is also what makes race conditions and deadlocks possible.
Workaround#: A temporary way around a problem that does not fix its cause. It gets work moving, but it can hide the real issue and linger for years. Add a comment or ticket so the proper fix is not forgotten.

Process and AgileBack to top

Acceptance criteria#: The conditions a story must meet to count as done and accepted. They are specific and testable, for example 'an error message appears when the password is too short'. They keep the team, testers and stakeholders on the same page.
Agile#: An approach that delivers software in small iterations and adapts to feedback instead of planning everything upfront. It values working software, collaboration and responding to change. Scrum and Kanban are common ways of practising it.
Backlog#: The ordered list of work the team might do, with the most important items at the top. Anyone can suggest items, and the product owner decides priority. A good backlog is kept tidy, so the top items are clear enough to start on.
Blocker#: Something that prevents progress on a task, such as a missing access right, an unanswered question or a broken environment. Raise it early, for example at stand-up. A blocker nobody mentions can stall work for days.
Definition of Done#: The team's shared checklist for work to count as complete. It often includes reviewed code, passing tests, updated documentation and deployment to a test environment. It applies to every story, unlike acceptance criteria, which are specific to one.
Definition of Ready#: The checklist a story must meet before the team starts work on it. It typically asks for clear acceptance criteria, an estimate and no unresolved dependencies. It prevents work from starting on items nobody understands yet.
Epic#: A large body of work that is too big for one sprint and is broken down into user stories. An example is 'let customers manage their account'. Epics help group related stories and track progress on a larger goal.
Kanban#: A flow-based way of working that shows tasks on a board with columns such as To do, In progress and Done. It limits work in progress so the team finishes things before starting new ones. Unlike Scrum, it has no fixed sprints.
MVP#: Minimum viable product: the smallest version that delivers real value to users. It is released early to learn what people actually need before more is built. Minimum does not mean low quality, only a narrow scope.
Proof of concept (PoC)#: A small experiment that shows an idea can work technically. It is built quickly and often thrown away afterwards. A PoC is not production-ready, so do not ship it as it stands.
Retrospective#: A regular meeting where the team looks back at how it worked and agrees improvements. A common format asks what went well, what did not and what to change. It only helps if the actions chosen are followed up.
SDLC#: Software development life cycle: the stages from idea to running software. Typical stages are planning, design, building, testing, release and maintenance. Waterfall, Agile and DevOps are different ways of organising and repeating these stages.
Spike#: A time-boxed investigation to answer a question or reduce uncertainty, such as whether a library can do what you need. The result is knowledge, a recommendation or a small prototype, and nobody expects finished code. The time limit stops it growing into open-ended research.
Sprint#: A fixed time-box of work in Scrum, typically one to four weeks. The team picks items from the backlog at the start and aims to finish them by the end. Each sprint normally ends with a review and a retrospective.
Stakeholder#: Anyone with an interest in, or influenced by, the outcome of the work. That includes users, customers, managers, other teams and the business. Knowing who they are tells you whose needs and approvals matter.
Stand-up#: A short daily team meeting, usually 15 minutes or less, held standing to keep it brief. Each person shares progress, plans and anything blocking them. Longer discussions are moved to a separate conversation afterwards.
Story points#: A relative measure of the effort, complexity and uncertainty of a story. They compare stories with each other and are not hours. Teams often use a scale such as 1, 2, 3, 5, 8, and the numbers only make sense within one team.
User story#: A short requirement written from the user's point of view, often as 'As a user, I want X so that Y'. It describes the need and the value, and leaves the technical solution open. Details are added through conversation and acceptance criteria.
Velocity#: The amount of work a team completes per sprint, usually counted in story points. Averaged over several sprints it helps with planning how much to take on next. It is a planning aid for the team and a poor way to compare teams or judge people.

QualityBack to top

Bug / defect#: Behaviour that differs from what is expected or required. A good bug report says what you did, what you expected, what happened and in which version or environment. That detail lets someone else reproduce and fix it.
Code review#: Examination of a change by a colleague before it is merged. Reviewers look for bugs, unclear code, missing tests and security problems, and they share knowledge about the codebase. Keep changes small so reviews stay quick and thorough.
End-to-end (E2E) test#: A test of a complete user flow through the whole system, often driving a real browser. It gives the most realistic confidence, for example that a customer can sign up and place an order. It is also the slowest and most fragile kind of test, so keep these few.
Integration test#: A test that checks several components working together, for example your code talking to a real database. It finds problems that unit tests miss, such as wrong assumptions between parts. These tests are slower and need more setup.
Mock / stub#: A stand-in for a real dependency during a test, such as a fake payment service. A stub returns fixed answers, while a mock also records how it was called so the test can verify it. They keep tests fast and independent of outside systems.
Performance test#: A test of speed, stability and capacity under load. Load testing uses expected traffic, and stress testing pushes past it to find the breaking point. Results show bottlenecks before real users hit them.
Regression#: Something that worked before and is now broken, usually because of a later change. Automated tests that run on every change exist mainly to catch regressions early. Regression testing means re-checking existing behaviour after a change.
Smoke test#: A quick check that the most basic functions work, such as the app starting and the login page loading. It is often run right after a deployment. If it fails, there is no point in running further tests.
Test coverage#: The share of code that is executed when the tests run, usually given as a percentage. Low coverage shows untested areas. High coverage does not prove the tests check anything useful, so treat the number as a hint.
UAT#: User acceptance testing: final testing done by the business or real users to confirm the software meets their needs. It runs in a production-like environment, often against agreed acceptance criteria. Sign-off from UAT is commonly required before release.
Unit test#: An automated test of one small piece of code, such as a function or class, in isolation. Unit tests run fast and pinpoint where something broke. They are usually the largest group of tests in a project.

Data, Architecture, and APIsBack to top

API#: Application programming interface: a defined way for one piece of software to talk to another. It specifies what you can ask for and what you get back, without exposing how it works inside. Web APIs are called over HTTP, but libraries have APIs too.
API gateway#: A single entry point in front of many APIs or services. It routes requests and often handles authentication, rate limiting and logging in one place. Clients then need to know only one address.
Cache#: A fast store of data that is expensive to fetch or compute, kept close to where it is needed. It speeds up repeated requests and reduces load on the source. The hard part is knowing when cached data is stale and must be refreshed.
Cookie / session#: Ways to recognise a user across requests, since HTTP itself keeps no memory. A cookie is a small piece of data the browser stores and sends back. A session is the server-side record that a cookie ties to, holding things like who is logged in.
CRUD#: Create, read, update, delete: the four basic operations on stored data. Many applications and APIs are largely CRUD, mapped to SQL statements or HTTP methods. The term is a quick way to describe simple data-handling features.
Endpoint#: A specific URL of an API that handles a particular kind of request, for example GET /users/42. Documentation lists the endpoints, the methods they accept and what they return. Each combination of URL and method does one job.
Event-driven#: A design where components react to events, such as order placed, instead of calling each other directly. Producers publish events and consumers decide what to do with them. This loosens coupling, but the flow of a request becomes harder to follow.
Header#: Metadata sent along with an HTTP request or response, as name and value pairs. Headers carry things like the content type, authentication tokens and caching rules. They are separate from the body, which holds the actual data.
Idempotent#: Describes an operation that gives the same result when repeated. Setting a value to 5 is idempotent, adding 1 to it is not. It matters because networks fail and requests get retried, so retried calls should not charge a customer twice.
Index#: A database structure that speeds up lookups on certain columns, much like the index of a book. Without one, the database may have to read every row. Indexes make writes slightly slower and take space, so add them where queries need them.
Latency#: The delay between sending a request and getting a response, usually measured in milliseconds. Distance, network hops and slow processing all add to it. Users notice latency more than raw capacity.
Message queue#: A buffer that passes messages between systems, so the sender does not wait for the receiver. If the receiver is slow or down, messages wait in the queue. RabbitMQ, Azure Service Bus and Amazon SQS are common examples.
Microservice#: A small, independently deployable service that does one job and talks to others over the network. Teams can build and release their services separately. The price is more moving parts to run, monitor and keep consistent.
Monolith#: An application built and deployed as a single unit. It is simpler to develop, test and run at first, and a good default for many projects. As it grows, changes can become harder to isolate and the whole system must be deployed together.
Payload#: The data carried by a request, response or message, as opposed to the headers and other metadata. In a web API it is typically a JSON body. Check its format and size when a call is rejected.
Primary key / foreign key#: A primary key is a column that uniquely identifies each row in a table. A foreign key is a column that refers to a row in another table, which links the two. Together they keep related data consistent, for example stopping an order from pointing to a customer that does not exist.
Query#: A request for data from a database, most often written in SQL. A query can filter, sort, join and summarise rows. Slow queries are a common cause of slow applications.
REST#: A common style for web APIs built on HTTP. Resources have URLs, and standard methods such as GET, POST, PUT and DELETE read or change them. Data usually travels as JSON, and each request stands on its own.
Schema#: The defined structure of a database or data format: tables, columns, types and relationships, or the allowed fields of a JSON document. A schema change, called a migration, must be handled carefully because existing data and code depend on it.
Status code#: A three-digit number in an HTTP response that tells you the outcome. 2xx means success (200 OK), 3xx means redirect, 4xx means the request was wrong (404 Not Found) and 5xx means the server failed (500). The first digit is the quickest clue to where the problem lies.
Throughput#: How much work a system processes per unit of time, such as requests per second. It is a different measure from latency: a system can answer each request slowly and still handle many at once. Performance tests usually report both.
Transaction#: A group of database operations that succeed or fail together. If one step fails, the whole group is rolled back and the data stays consistent. A bank transfer is the classic example: the debit and the credit must both happen or neither.
Webhook#: A callback where one system notifies another by sending an HTTP request when something happens. For example, GitHub can call your server when code is pushed. It saves polling, but the receiving side must be reachable and should verify who sent the request.

Infrastructure and CloudBack to top

Container#: A lightweight, isolated package of an application and the things it needs to run. Containers share the host's operating system kernel, so they start fast and use less than VMs. Docker is the best-known tool, and the same image behaves the same on any machine.
DNS#: Domain Name System: the system that maps names like example.com to IP addresses. Answers are cached for a set time, so changes can take a while to reach everyone. When a site is unreachable by name but works by IP address, DNS is a prime suspect.
Environment#: A place where the software runs, such as development, test, staging or production. Each has its own configuration, data and access rules. Keeping them similar reduces surprises when code moves from one to the next.
Firewall#: A filter that allows or blocks network traffic according to rules, such as which ports and addresses may connect. It can run on a machine or as part of the network. A connection that hangs without an error is often blocked by a firewall.
IaaS / PaaS / SaaS#: Infrastructure, platform or software offered as a service. With IaaS you rent servers and manage the rest, with PaaS you deploy code onto a managed platform, and with SaaS you use a finished application. The further along, the less you manage and the less you control.
Infrastructure as Code#: Describing servers, networks and other infrastructure in versioned files instead of setting them up by hand. Tools such as Terraform, Bicep and CloudFormation read these files and create the resources. You get repeatable setups, code review and a history of changes.
Localhost#: A name for your own machine, addressed from itself. It resolves to the IP address 127.0.0.1, so a service reached at localhost is only reachable from your computer. Local development servers usually run there, with a port number such as localhost:3000.
Port#: A numbered endpoint on a machine for network traffic, so one computer can run many services at once. Well-known examples are 80 for HTTP, 443 for HTTPS and 22 for SSH. 'Address already in use' means another program is already listening on that port.
Production (prod)#: The live environment used by real users and holding real data. Changes there carry real consequences, so access is restricted and deployments are careful. Never test experiments in production.
Proxy#: An intermediary that forwards network requests on behalf of someone else. A forward proxy sits in front of users, and a reverse proxy sits in front of servers. Proxies are used for caching, filtering, load balancing and hiding internal systems.
Region#: A geographic location where a cloud provider has data centres, for example West Europe or US East. Choosing a region affects latency, cost, available services and where data is stored. Legal rules about data location can limit your choice.
Scalability#: The ability of a system to handle more load. Scaling up gives a server more power, and scaling out adds more servers. Designs that keep no state on one machine are much easier to scale out.
Server#: A computer or program that serves requests from other computers or programs, called clients. A web server returns pages, and a database server answers queries. The word can refer to the hardware or to the software running on it, so context decides which.
Staging#: A production-like environment used for final checks before a release. It mirrors production as closely as practical in setup and configuration. Problems found here do not affect real users.
VM#: Virtual machine: a virtual computer with its own operating system, running on shared physical hardware. Several VMs can share one host, isolated from each other. They are heavier than containers but offer strong separation.

SecurityBack to top

Authentication#: Proving who you are, for example with a password, a code or a key. It answers the question 'who is this?'. Often shortened to authn, and always a separate step from authorization.
Authorization#: Determining what an authenticated user is allowed to do. It answers 'may this person do this?' and is checked on every action, based on roles or permissions. Often shortened to authz.
Encryption#: Reversible scrambling of data using a key, so only someone with the right key can read it. It protects data at rest, such as on disk, and in transit, such as over a network. Unlike hashing, you can get the original data back.
Hashing#: A one-way conversion of data to a fixed-size value that cannot be turned back into the original. It is used to store passwords and to check file integrity. For passwords use a slow, salted algorithm such as bcrypt or Argon2, not a plain fast hash.
Least privilege#: Granting only the access that is needed to do a job, and no more. A service that only reads data should not have rights to delete it. If an account is compromised or makes a mistake, the damage is limited.
MFA#: Multi-factor authentication: requiring more than one proof of identity, such as a password plus a code from an app or a hardware key. A stolen password alone is then not enough. Turn it on wherever it is offered.
OAuth#: A standard for delegating access without sharing passwords. It is what lets you click 'Sign in with Google' or allow an app to read your calendar. The app receives a limited token instead of your credentials.
PII#: Personally identifiable information: data that can identify a person, such as a name, email address, phone number or national ID. Laws like the GDPR set rules for collecting, storing and sharing it. Avoid putting PII in logs, test data and examples.
Secret#: A credential or key that must be protected, such as a password, API key or connection string. Never commit secrets to source control, even in a private repository. Store them in a secret manager or environment configuration, and rotate any that leak.
SSO#: Single sign-on: one login that gives access to many applications. A central identity provider checks who you are and tells each application. Users juggle fewer passwords, and admins can turn off access in one place.
TLS / HTTPS#: TLS is the protocol that encrypts communication between two systems and confirms the server's identity with a certificate. HTTPS is HTTP carried over TLS. It stops others on the network from reading or changing traffic, and expired certificates are a common cause of sudden outages.
Token#: A credential issued after authentication, which the client sends with later requests to prove its identity or permissions. Examples are access tokens and JSON Web Tokens (JWT). Treat tokens like passwords, because anyone holding one can use it until it expires.
Vulnerability#: A weakness in software or configuration that can be exploited to cause harm, such as injection flaws or outdated libraries. Known ones are published with CVE numbers. Keeping dependencies updated and scanning for issues reduces your exposure.

OperationsBack to top

Alert#: An automatic notification that something is wrong or about to be, triggered by a rule on logs or metrics. A useful alert tells someone what to look at and needs action. Too many noisy alerts lead people to ignore them, including the real ones.
CI/CD#: Continuous integration and continuous delivery (or deployment): automated pipelines that build, test and deliver changes. CI runs the build and tests on every push. CD takes the result onward to an environment, so releases become routine.
Code freeze#: A period when no new changes may be merged, usually before a major release or during a busy business time. It gives the team room to test and stabilise. Only critical fixes get through, with extra approval.
Deployment#: Putting a new version of the software into an environment where it runs. It can be manual or automated, and it often means building, copying files, running migrations and restarting services. Frequent, small, automated deployments are safer than rare, large ones.
Hotfix#: An urgent fix applied outside the normal release cycle, usually to production. It is kept as small as possible to limit risk. The fix should also be merged back into the main line so it is not lost.
Incident#: An unplanned disruption or degradation of a service. Handling it usually means detecting it, communicating, restoring service and then reviewing what happened. Restoring service comes first, and finding the full cause can wait until afterwards.
Observability#: How well you can understand what a system is doing from the outside, using logs, metrics and traces. Logs record events, metrics count and measure, and traces follow a request across services. Good observability turns 'it is slow somewhere' into a specific answer.
On-call#: Being the person responsible for responding to incidents outside normal hours, usually in a rotation. You carry a phone or pager and act when an alert fires. Good runbooks and sensible alerts make it manageable.
Outage#: A period when a service is unavailable to its users. It may be total or partial, planned or unplanned. Its length and impact are tracked and often feed into SLAs and reviews.
Post-mortem#: A review after an incident to learn what happened and why. A blameless post-mortem looks at the system and the process, and does not look for someone to blame. It ends with concrete actions to prevent a repeat.
Release#: A version of the software made available to its users. A release is normally identified by a version number and described in release notes. It is a good habit to tag the commit that was released.
Rollback#: Returning to a previous working version after a bad release. Being able to roll back quickly is a basic safety net. It gets harder when the new version has already changed the database, so plan for that beforehand.
Root cause#: The underlying reason a problem occurred, as opposed to the visible symptom. Fixing only the symptom means the issue returns. Asking 'why' repeatedly, as in the five whys technique, helps to dig down to it.
Runbook#: Step-by-step instructions for operating or fixing a system, for example what to do when the queue backs up. It lets someone who did not build the system act under pressure. Keep runbooks current, because outdated ones mislead.
SLA / SLO#: A service level agreement (SLA) is a promise to customers about service quality, often with penalties, such as 99.9 percent uptime. A service level objective (SLO) is the internal target the team aims for, usually stricter than the SLA. Both give a measurable idea of 'good enough'.