The reason usually isn’t incompetence. It’s ownership. Engineering optimises for shipping features and keeping things up. Finance sees a single monthly invoice with no visibility into what drives it. In between, nobody is specifically accountable for the number going up.

The good news is that most cloud waste comes from a small, predictable set of causes. This article walks through the six most common ones we see, what each typically costs, and roughly what fixing it is worth. It’s written for founders and CTOs — you shouldn’t need to be a DevOps engineer to follow it.

One caveat before we start: every percentage below is a typical range, not a guarantee. Real savings depend entirely on your architecture and workload. Treat these as places to look, not promises.

1. Servers Running at 12% CPU

This is the single most common source of waste, and it has an entirely human explanation.

Early in a project, someone has to pick an instance size. There’s no production traffic data yet, the cost of being under-provisioned (an outage) feels far worse than the cost of being over-provisioned (a slightly bigger bill), so they round up “to be safe.” That’s a reasonable decision at the time.

The problem is that nobody ever revisits it. Two years later, that instance is still running, still oversized, and still billing every hour.

How to check

In CloudWatch, look at average CPU utilisation across 30 days for your EC2 instances and RDS databases. Sustained utilisation below 20% is a strong signal you’re paying for roughly four times the machine you need. AWS Compute Optimizer will also generate right-sizing recommendations automatically, and it’s free.

A word of caution: CPU isn’t the whole picture. Some workloads are memory-bound or I/O-bound and will show low CPU while genuinely needing the instance. Check memory and network metrics before downsizing anything, and change one instance at a time.

Typical saving: 30–50% of EC2 spend.

2. Paying On-Demand Prices for Predictable Workloads

On-demand pricing exists so you can spin up capacity instantly without commitment. You pay a premium for that flexibility, and for genuinely unpredictable workloads, it’s worth it.

But your production database isn’t unpredictable. Neither is your main application server. These run continuously, every hour of every day, and they will still be running next year. Paying a flexibility premium for something completely predictable is pure waste.

AWS offers two main alternatives for committed usage:

• Savings Plans — you commit to a consistent dollar amount of compute usage per hour for one or three years, in exchange for significantly lower rates. Compute Savings Plans are the flexible option, applying across instance families, regions, and even Fargate and Lambda.
• Reserved Instances — a more specific commitment tied to instance attributes, still widely used for RDS and other services.

AWS advertises discounts of up to roughly 72% for the deepest three-year, all-upfront commitments. Most companies won’t hit that ceiling, but even a one-year, no-upfront Compute Savings Plan typically delivers meaningful double-digit savings with very little downside.

There’s also Spot Instances — spare AWS capacity at discounts that can reach around 90%, with the catch that AWS can reclaim the capacity with two minutes’ notice. Never use Spot for your primary database. It’s excellent for batch processing, CI/CD runners, data pipelines, and any fault-tolerant workload that can be interrupted and resumed.

Typical saving: 20–40% of compute spend.

3. Development Environments Running All Night

Your team works something like 45 to 50 hours a week. Your development and staging environments bill for all 168.

That means for roughly 70% of every week, you’re paying full price for environments with nobody logged into them. Unlike production, these environments have no uptime requirement whatsoever. If staging is down at 3am on a Sunday, nothing happens.

How to fix it

A scheduler that stops non-production instances outside working hours is genuinely a one-afternoon piece of work. AWS Instance Scheduler is a supported solution for this, but a simple Lambda function on an EventBridge schedule works just as well — stop instances at 8pm, start them at 8am, skip weekends.

The main objection is usually “but what if someone needs it at night?” In practice, giving the team a self-service way to start an environment on demand solves this completely, and the exceptions are rare enough that the savings hold.

Typical saving: 65–70% of non-production spend.

4. Storage for Servers That No Longer Exist

This is the most frustrating category, because you get absolutely nothing in return for the money.

When you terminate an EC2 instance, its attached EBS volume doesn’t always go with it — depending on how it was configured, the volume can survive, unattached to anything, billing every month indefinitely. The same happens with:

• Orphaned EBS snapshots. Teams take snapshots before risky changes and never clean them up. Years of them accumulate.
• Unattached Elastic IPs. AWS charges for Elastic IP addresses that aren’t associated with a running instance.
• Idle load balancers. A load balancer left behind after a service was decommissioned bills an hourly rate for doing nothing.
• Empty or unused NAT Gateways. These carry an hourly charge regardless of whether traffic flows through them.

None of this is serving a user. None of it is supporting a workload. It’s abandoned infrastructure that nobody remembered to delete.

AWS Trusted Advisor flags several of these categories directly. A quarterly cleanup review is usually enough to keep it under control. For most mid-sized companies this recovers a few hundred dollars a month; for larger or older accounts, it can be dramatically more.

Typical saving: highly variable, but always pure profit — nothing is lost by removing it.

5. Data Transfer Costs You Can’t See

This is the sneakiest category on the list, because the charges don’t appear next to the resources causing them.

Two things dominate here:

NAT Gateway processing charges

NAT Gateways charge both an hourly rate and a per-gigabyte data processing fee for everything passing through them. If your services in private subnets are pulling large amounts of data from the internet — container images on every deployment, package downloads, external API calls — that processing fee accumulates quietly.

The common fix is VPC Endpoints. Traffic to services like S3 and DynamoDB can route through an endpoint instead of the NAT Gateway, avoiding the processing charge entirely for that traffic.

Cross-availability-zone traffic

AWS charges for data moving between availability zones inside the same region — in both directions. This is the one that catches teams out.

If you’ve split a chatty set of microservices across multiple AZs for resilience, every internal call between them may now be a billable cross-AZ transfer. You did the architecturally responsible thing and got a surprise line item for it.

The answer isn’t to abandon multi-AZ redundancy — that’s there for good reason. It’s to be deliberate about which services genuinely need to talk across zones, and to keep high-volume chatty communication zone-local where availability requirements allow.

Typical impact: often 5–15% of the total bill, and almost always underestimated.

6. Logs and Backups You Will Never Read

By default, CloudWatch log groups retain data indefinitely. Not for 30 days, not for a year — forever, unless someone explicitly sets a retention policy.

That means many companies are paying premium storage rates to keep application logs from years ago that no human will ever open. The same applies to S3 buckets without lifecycle rules, where data that’s been untouched for years still sits in the most expensive storage class.

The two fixes

• Set CloudWatch retention policies. Decide how long logs are actually useful — 30, 60, or 90 days for most application logs — and configure it. Anything you need for compliance can be exported to cheaper storage first.
• Use S3 lifecycle policies and storage classes. S3 offers a range of tiers, from Standard down to Glacier Deep Archive, at dramatically different price points. S3 Intelligent-Tiering will move objects between access tiers automatically based on usage, which is a reasonable default when access patterns are unpredictable.

Both are configured once and keep saving money indefinitely, with no ongoing effort.

Typical saving: modest as a percentage, but permanent and effortless.

Where to Actually Start

If you do nothing else, do this: open AWS Cost Explorer, group your spend by service, and look at your top three lines.

Cloud bills follow a Pareto pattern almost universally. A small number of services account for the overwhelming majority of the cost. Optimising a service that represents 2% of your bill is a poor use of engineering time, no matter how inefficient it is. Start where the money actually is.

Three practices matter more than any individual optimisation:

• Tag everything. Without resource tags for environment, team, and project, you can’t attribute cost to anything. Cost allocation tags turn an opaque invoice into an actionable breakdown.
• Set budget alerts. AWS Budgets can notify you when spend crosses a threshold or is forecast to. Finding out about a cost spike on the 3rd rather than the 30th is the difference between a small problem and a large one.
• Give the bill an owner. Not a committee — a named person who reviews it monthly and is expected to explain changes. This single organisational change tends to outperform any technical fix.

Cloud spend isn’t a technical problem. It’s an ownership problem.

A Note on Over-Optimising

It’s worth saying the obvious counterpoint: cost optimisation has diminishing returns, and engineering time isn’t free.

If your monthly AWS bill is $800, spending three engineer-weeks to save 20% is a bad trade. If it’s $80,000, the same effort is obviously worth it. And some spending that looks wasteful is actually buying you something real — multi-AZ redundancy costs more and is usually correct; over-provisioned capacity ahead of a known traffic event is prudent, not careless.

The goal isn’t the lowest possible bill. It’s a bill where every line item is a decision someone made on purpose.

How We Approach This at Onclick Innovations

We build and maintain cloud infrastructure for clients across fintech, healthcare, e-commerce and SaaS, and cost efficiency is something we treat as an architectural concern from the start rather than a cleanup exercise later. Right-sizing, environment scheduling, storage lifecycle rules and sensible tagging are far cheaper to build in at the beginning than to retrofit onto a system that’s already running in production.

Frequently Asked Questions

How much are most companies overspending on AWS?
Industry analyses of cloud spending consistently estimate that roughly 30% of cloud spend is wasted across the market. The figure for any individual company varies widely depending on architecture, workload predictability, and whether anyone actively reviews the bill.

What’s the fastest way to reduce an AWS bill?
Usually two things: right-sizing over-provisioned instances, and scheduling non-production environments to shut down outside working hours. Both are relatively quick to implement and carry low risk compared to architectural changes.

What’s the difference between Savings Plans and Reserved Instances?
Savings Plans commit you to a consistent hourly dollar amount of compute usage and apply flexibly across instance families, regions, and services including Fargate and Lambda. Reserved Instances are tied more specifically to instance attributes. Savings Plans are generally the more flexible option for EC2 compute; Reserved Instances remain common for services like RDS.

Are Spot Instances safe to use?
For the right workloads, yes. AWS can reclaim Spot capacity with two minutes’ notice, so they should never run your primary database or anything that can’t tolerate interruption. They’re well suited to batch jobs, CI/CD runners, data processing, and other fault-tolerant workloads.

Why is AWS data transfer so expensive?
Data transfer charges come from several sources, most commonly NAT Gateway per-gigabyte processing fees and cross-availability-zone traffic within a region. They’re easy to miss because the charges don’t appear alongside the resources generating them. VPC Endpoints and keeping high-volume internal traffic zone-local are the usual mitigations.

What tools does AWS provide for cost management?
Cost Explorer for analysing spend, AWS Budgets for alerts and forecasting, Compute Optimizer for right-sizing recommendations, and Trusted Advisor for flagging idle and unused resources. All are available within the AWS console.

Share

The post 6 Things Silently Inflating Your AWS Bill — And What Each One Is Actually Worth appeared first on Blog.

In 2026, JioHotstar reported a peak of roughly 72.5 million concurrent viewers during the ICC Men’s T20 World Cup final — a figure Reliance cited as a global record for a single live stream. To put that in perspective, the Super Bowl, the biggest live event in American media, peaks at somewhere around 10 to 12 million concurrent streams. JioHotstar routinely handles six to seven times that number, on a network where the same match is being watched on a 5G phone in Mumbai and a patchy 2G connection in rural Bihar at the same time.

How does a single platform pull this off without the whole thing collapsing? The answer is a genuinely fascinating piece of engineering. Here’s a breakdown of what actually makes it work.

First, A Note on the Numbers

Cricket streaming numbers in India get thrown around loosely, so it’s worth being precise. There are two very different metrics that often get confused:

• Concurrent viewers — how many people are watching at the exact same moment. This is the hard engineering number. JioHotstar’s verified peak here is around 72.5 million.
• Cumulative reach — how many unique people watched at any point across a match or a tournament. This is where you see figures in the hundreds of millions or billions (IPL 2025 reportedly drew over a billion viewers across TV and digital combined).

Both are real, but they measure completely different things. The concurrency number is the one that keeps engineers awake at night, because that’s the load the system has to survive in a single instant. Everything below is about how that instant is handled.

The Core Problem: Cricket Traffic Isn’t Smooth, It’s Explosive

Most streaming platforms deal with fairly predictable demand. People start a Netflix show whenever they feel like it, spread across the evening. Cricket does the opposite.

Hotstar’s own engineers have described traffic that can spike 20x within ten minutes of a match starting. Worse, the spikes happen mid-match too. When a star batter walks out to the crease, or a wicket falls in a tense final over, millions of people who stepped away suddenly rush back at once. Tens of millions of users can join within a single over.

This creates a specific, brutal engineering challenge called the thundering herd: a huge number of clients all requesting the same thing at the same instant, potentially overwhelming any server that isn’t ready for them. The entire architecture is designed around surviving these sudden surges, not just handling a high steady load.

Building Block 1: Adaptive Bitrate Streaming

The single most important idea in mass live streaming is that not everyone gets the same video. Through a technique called adaptive bitrate (ABR) streaming, the platform encodes every live stream into multiple quality versions simultaneously — 4K, 1080p, 720p, 480p, 360p, and stripped-down low-bandwidth versions for 2G connections.

The app on your phone constantly measures your available bandwidth and picks the right version, switching seamlessly if your connection changes — without ever interrupting playback. A viewer on stadium Wi-Fi might get 360p while a viewer on home fibre gets 4K, both watching the same match from the same infrastructure, just receiving different renditions.

This isn’t a nice-to-have. In a country with wildly varying network quality, ABR is the core mechanism that lets one platform serve everyone at once instead of buffering for half of them.

Building Block 2: A Multi-CDN Strategy

Here’s a physics problem: delivering video to 70 million people simultaneously from a central set of servers is simply impossible. The bandwidth doesn’t exist. The solution is the Content Delivery Network (CDN) — a globally distributed network of edge servers that cache content close to viewers.

JioHotstar doesn’t rely on just one. It runs a multi-CDN strategy, distributing traffic across several providers (Akamai has long been a core partner, alongside others) and using an in-house load optimizer that dynamically routes each viewer through the least-congested CDN in real time, based on live measurements of latency and packet loss. If one provider starts struggling, traffic shifts to another automatically.

The result of all this caching is dramatic: during live cricket, over 90% of content requests are served from CDN cache rather than origin servers. That single fact is the biggest scaling lever in the whole system. At a 90% cache hit rate, the origin infrastructure only has to handle roughly a tenth of the apparent load — still enormous, but survivable.

Cache hit rate is the primary scaling lever. At 90%, the platform serves ten times the load its origin servers actually see.

Building Block 3: The Custom Autoscaler

Behind the video, hundreds of microservices handle everything else: login, subscriptions, live scores, chat, reactions, recommendations, payments. These run on a massive Amazon EKS (Elastic Kubernetes Service) cluster — at peak, the setup has been described as running on the order of 16 TB of RAM, 8,000 CPU cores, and 32 Gbps of peak data transfer.

The clever part is how it scales. Standard Kubernetes autoscaling reacts to CPU and memory usage — but by the time CPU climbs, the surge has already arrived and viewers are already buffering. A newly provisioned server can take around 90 seconds to become healthy and start serving traffic, and in cricket, 90 seconds is two overs and several million viewers too late.

So JioHotstar’s engineers built a custom autoscaler that reacts to concurrency directly — the actual number of active streams — rather than to lagging server metrics. It can spin up new capacity within about 30 seconds of detecting a rising trend, giving it a crucial 60-to-90-second head start over standard tooling.

Building Block 4: Prewarming and Predicting the Surge

Even a fast autoscaler is reactive. The most sophisticated part of the strategy is being proactive. Rather than waiting for load to arrive, the team prewarms infrastructure ahead of big matches — provisioning servers and load balancers in advance, based on estimated peak concurrency drawn from years of historical match data.

Cricket is unusually predictable in this respect. Engineers know an India-Pakistan game will draw a bigger crowd than a mid-table league fixture, and they know viewership climbs toward the final overs. That historical pattern lets them pre-position capacity for the wave before it hits, treating reactive autoscaling as a backup rather than the front line.

The Clever Optimizations Most People Never Notice

Beyond the big architectural pieces, some of the most interesting work is in the small optimizations that shave load off the system:

• Separating cacheable from non-cacheable data. Not every request is equal. A live scorecard or match summary doesn’t change every second, so it can be cached and reused. Engineers separated these cacheable APIs onto a dedicated path with lighter security checks and faster routing, dramatically increasing how many users each server could handle.
• Slowing down refresh rates that don’t matter. Features like “watch more” suggestions or certain stats overlays don’t need real-time updates. By slightly reducing how often they refresh, the platform cut total network traffic without any viewer noticing a difference.
• Accepting a small, deliberate delay. JioHotstar streams run roughly 30 to 40 seconds behind the live TV broadcast. This isn’t a flaw — it’s a deliberate trade-off. That buffer is exactly what gives the system room to handle adaptive bitrate switching and absorb network hiccups without the stream stalling.
• Feature flags for safe rollouts. New features (interactive overlays, new quality options) are rolled out to a small percentage of viewers first. If something breaks under real load, it can be switched off instantly for everyone without touching the core stream.

The Jio Advantage Nobody Else Has

There’s one structural advantage worth calling out. Because JioHotstar sits inside Reliance, it has a relationship with Jio’s telecom network and its 450-million-plus subscribers that no independent streaming platform can replicate.

That telecom data can inform where CDN edge nodes are placed — pre-positioning capacity in regions where network data shows dense cricket viewership before a match even begins. Controlling both the last-mile network and the streaming platform is a genuine edge in a market this large and this network-diverse.

Why This Matters Beyond Cricket

It’s tempting to file this under “interesting cricket trivia,” but the engineering lessons are universal. The Netflix livestream of the Jake Paul vs. Mike Tyson fight in late 2024 buffered and stuttered for many viewers — a reminder that even one of the most sophisticated streaming companies in the world can struggle with live sport when it hasn’t been engineered specifically for these explosive, unpredictable spikes.

The principles JioHotstar relies on — cache aggressively and treat cache misses as the exception, scale on the metric that actually predicts load, prepare for the surge before it arrives, and make deliberate trade-offs like accepting a few seconds of latency for stability — apply to any system that has to survive sudden, massive concurrency. That includes ticketing platforms during a sale, payment systems on a festival day, and any product that goes from quiet to viral in minutes.

At Onclick Innovations, this is exactly the class of problem we love: architecting systems that stay fast and reliable not on an average day, but on the single worst-case moment when everyone shows up at once. The best infrastructure isn’t the kind that handles a steady load. It’s the kind you never notice, precisely because it was built for the spike.

Frequently Asked Questions

How many people watch JioHotstar at the same time during big matches?
JioHotstar reported a peak of roughly 72.5 million concurrent viewers during the ICC Men’s T20 World Cup final in 2026, cited by Reliance as a global record for a single live stream. Cumulative reach across a full match or tournament runs far higher, into the hundreds of millions, but that counts unique viewers over time rather than at a single moment.

What cloud infrastructure does JioHotstar use?
The platform runs primarily on Amazon Web Services, using Amazon EKS (managed Kubernetes) to orchestrate its microservices, alongside a multi-CDN delivery strategy with partners such as Akamai. It uses a mix of on-demand and spot instances to manage cost at scale.

Why doesn’t JioHotstar buffer during peak cricket traffic?
A combination of adaptive bitrate streaming (serving different quality levels to different viewers), aggressive CDN caching that handles over 90% of requests, a custom autoscaler that reacts to concurrency in about 30 seconds, and prewarming infrastructure ahead of matches based on historical data.

Why is the JioHotstar stream a bit behind the TV broadcast?
The stream runs roughly 30 to 40 seconds behind live TV. This is a deliberate engineering trade-off — the delay creates a buffer that allows adaptive bitrate switching and absorbs network fluctuations, keeping the stream stable for tens of millions of viewers at once.

What is the thundering herd problem in live streaming?
It’s when a very large number of viewers request the same content at the same instant — for example, millions rushing back to the stream when a wicket falls — potentially overwhelming servers. Streaming platforms design specifically around absorbing these sudden surges rather than just handling steady high load.

Sources: figures and technical details in this article are drawn from Reliance’s public statements, Business Standard, published Hotstar/JioHotstar engineering talks and case studies, and industry technical analyses (2019–2026). Some detailed architecture specifics reported by third parties are described by those sources as informed inference rather than officially confirmed by JioHotstar.

Share

The post How JioHotstar Streams Cricket to 70+ Million People at Once Without Buffering appeared first on Blog.

No major rewrite has replaced it. No well-funded startup has dethroned it. Every serious alternative that’s launched since — and there have been several — has ended up either wrapping Git, integrating with Git, or quietly fading out. In an industry that reinvents itself every eighteen months, that kind of staying power is worth asking about.

Built Out of Frustration, Not Ambition

Git wasn’t built as a product. It was built because the Linux kernel team lost access to the proprietary tool (BitKeeper) they’d been using, and Torvalds needed a replacement fast — one that could handle a codebase with thousands of contributors and no central authority forcing everyone to work the same way.

That constraint shaped everything about how Git works. It had to be distributed, because Linux kernel development has never had one central server everyone depends on. It had to be fast, because kernel commits happen constantly. And it had to trust developers to work independently and merge later, rather than requiring permission before every change.

Those weren’t marketing decisions. They were survival decisions for one specific, enormous open-source project. It just turned out that nearly every software team on Earth had the same underlying problem.

What Actually Makes Git Different

Version control existed before Git. CVS, Subversion, and Perforce were all in wide use in 2005. What set Git apart wasn’t that it tracked changes — it was how it tracked them.

• Fully distributed. Every developer’s local copy is a complete repository with full history, not a thin client talking to a central server. You can commit, branch, and view history with zero network connection.
• Cheap, fast branching. Creating a branch in older systems could be a slow, heavyweight operation. In Git, it’s close to instant, which is what made feature branches, pull requests, and modern code review workflows practical in the first place.
• Content-addressed storage. Git identifies every piece of data by a hash of its content, not by filename or location. That’s the underlying reason Git is so good at detecting duplicate content, verifying integrity, and handling merges intelligently.
• No single point of failure. Because every clone is a full repository, losing the server doesn’t mean losing the project. Any developer’s machine can restore the whole history.

None of these ideas were entirely new in computer science. What Git did was combine them into a tool fast and reliable enough that teams stopped thinking about version control as a constraint and started treating it as infrastructure they didn’t need to worry about.

GitHub Didn’t Make Git Popular — It Made Git Social

It’s a common mix-up: many developers who started their careers after 2010 assume Git and GitHub are basically the same thing. They’re not. Git is the version control system running on your machine. GitHub, launched in 2008, is a hosting platform built on top of it.

What GitHub actually did was take Git’s distributed model and add a social and collaborative layer on top: pull requests, code review threads, issues, forks you could contribute back from, and eventually a de facto resume for developers. GitLab and Bitbucket followed with their own takes on the same idea.

That combination — Git’s technical model plus a platform for open collaboration — is arguably what pushed Git from “the tool Linux uses” to the default choice for nearly every kind of software project, open source or private.

Every Attempt to Replace It Has Failed — Or Just Joined It

Git has had real competition. Mercurial launched the same year as Git and, for a while, was considered by many to have a friendlier command-line interface. Some large companies, including Facebook for a period, invested heavily in alternatives or in heavily customized Git internals (Facebook eventually built Sapling, and Google has long used a modified, monorepo-focused workflow).

None of these efforts displaced Git at the industry level. The pattern that keeps repeating is telling: companies that need something different from stock Git tend to build tooling on top of Git rather than replace it outright. The underlying object model and distributed design have proven durable even when the workflow layered on top changes completely.

The Learning Curve Nobody Talks Their Way Out Of

Ask almost any developer, junior or senior, and you’ll hear some version of the same story: Git was confusing at first. Commands like rebase, cherry-pick, and reflog are genuinely hard to reason about the first time you encounter them, and a botched merge can still produce a moment of real panic.

That difficulty is part of why Git has stayed relevant rather than a reason it should have been replaced. The complexity isn’t accidental — it’s the visible surface of a genuinely powerful underlying model. Once a developer understands what a commit, a branch, and a merge actually represent internally, the commands stop feeling arbitrary and start feeling like direct, honest access to the data. Tools that hide that complexity behind friendlier interfaces tend to work fine until something goes wrong, at which point understanding the Git model underneath becomes the only way out.

Why Git Survived the AI Coding Wave

2026 has brought a wave of AI coding assistants, autonomous coding agents, and AI-native development workflows. It would have been reasonable to expect version control itself to get reinvented along with everything else.

Instead, AI coding tools have overwhelmingly built on top of Git rather than around it. AI agents commit through Git. Code review tools built for AI-generated pull requests still rely on Git’s diff and merge model. Even tools designed to let AI agents work autonomously across a codebase use Git branches and commits as the underlying record of what changed and why.

That’s not a coincidence. Git’s content-addressed, immutable history is exactly the kind of structure that makes it possible to track, audit, and roll back AI-generated changes with confidence — something that matters more, not less, as more code gets written by autonomous agents rather than humans typing directly.

What 21 Years of Git Says About Good Infrastructure

Git’s longevity says something bigger about how durable technical decisions actually work. It wasn’t designed to be a product, to be easy to learn, or to win a popularity contest. It was designed to solve one hard, specific problem correctly, at scale, under real constraints.

Software teams evaluating new tools and frameworks in 2026 are often chasing the newest option. Git is a reminder that the tools with the longest lifespans are usually the ones built to solve a real structural problem well, not the ones built to be trendy. Frameworks come and go. The version control layer underneath them has stayed remarkably stable for over two decades.

At Onclick Innovations, every project we build — regardless of the framework, language, or client industry — runs on Git. It’s one of the few pieces of the stack we never have to debate.

Frequently Asked Questions

How old is Git in 2026?
Git was created by Linus Torvalds in April 2005, making it 21 years old in 2026.

Why was Git created?
Git was built because the Linux kernel development team lost access to the proprietary version control tool they had been using and needed a fast, distributed replacement capable of handling a massive, decentralized open-source project.

Is Git the same thing as GitHub?
No. Git is the version control system itself, run locally on a developer’s machine. GitHub is a hosting platform, launched in 2008, built on top of Git that adds collaboration features like pull requests and issue tracking. GitLab and Bitbucket are similar hosting platforms.

Has anything replaced Git?
No mainstream alternative has replaced Git at an industry level. Some large companies have built customized tooling on top of Git’s core model for specific needs, but Git itself remains the dominant underlying version control system.

Why does Git still matter in the age of AI coding tools?
AI coding assistants and autonomous coding agents in 2026 are built on top of Git rather than replacing it, because Git’s immutable, content-addressed history makes it possible to track, audit, and roll back AI-generated code changes reliably.

Share

The post Git Just Turned 21 — Here’s Why Every Developer Still Can’t Escape It appeared first on Blog.