There is a version of the eCourts story told entirely in complaints. The portals are slow. The search does not work the way you want. Orders are missing. Metadata is inconsistent. Every one of those complaints is fair, and every one of them is made possible by the programme itself, because before eCourts there was nothing to complain about. There was a clerk, a register, and a physical trip to the court.
It is worth being precise about what the eCourts project is, what each phase set out to do, and what it actually delivered, because this is the single most consequential piece of legal infrastructure built in India in the last thirty years and it is discussed mostly through anecdote. This piece is an assessment: generous where the programme deserves it, specific where it falls short.
What the Project Actually Is
eCourts is a centrally sponsored mission mode project for information and communication technology in the Indian judiciary, implemented in phases. Its policy direction comes from the e-Committee of the Supreme Court of India, which drafted the national policy and action plan that the programme has followed since its inception. Implementation is a partnership: the e-Committee sets direction, the National Informatics Centre builds and operates the software, High Courts drive rollout in their States, and funding flows through the Department of Justice.
The technical core is the Case Information System, a common software application deployed across court establishments, with variants for the district judiciary and for the High Courts. Every piece of public-facing judicial data in India, from a case status lookup to a national pendency dashboard, is downstream of records created in that system by staff at a court establishment.
That last sentence is the most important structural fact about Indian judicial data, and it explains almost everything about its strengths and weaknesses. The data is not compiled by a statistics agency. It is a byproduct of court administration, entered by people whose primary job is running a court.
The Phases, and What Each One Was For
| Phase | Broad period | Principal objective | What it actually produced |
|---|---|---|---|
| Phase I | From 2007 | Basic computerisation: hardware, connectivity, and a common case management application in district court complexes | Court complexes with computers and local area networks, staff trained on the Case Information System, and the first machine-readable case registers. |
| Phase II | From around 2015 | Services on top of the base: national dashboards, public case status, judgment search, e-filing, e-payments and video conferencing capability | The National Judicial Data Grid, public case status and judgment search, the eCourts services application and SMS and email notifications, plus the video conferencing capacity that carried the courts through the pandemic. |
| Phase III | Approved in 2023 | A digital-first judiciary: unified technology platform, digitisation of legacy records, paperless courts, expanded e-filing, and online dispute resolution | In progress. The stated ambition is to move from digitising a paper process to designing a digital one, which is a different and much harder thing. |
The phase structure is worth taking seriously rather than treating as bureaucratic packaging. Phase I built the pipes. Phase II built services on them. Phase III is an attempt to redesign the process rather than automate the existing one, and that is where projects of this kind usually either succeed properly or stall.
What Genuinely Works
Start with the successes, because they are substantial and they are routinely understated by people who never had to work without them.
Case status at national scale
A litigant anywhere can look up the status and next date of a matter in a district court anywhere else. That was simply not possible before, at any price. It is the single largest access improvement the programme delivered.
A stable national case identifier
The CNR number gives each case a unique identifier that persists across transfers and renumbering. It is the closest thing Indian litigation has to a primary key, and its existence makes reconciliation across systems possible at all.
Judgment and order publication
High Court and district court judgments and orders are published through a consolidated search alongside each court's own site. Coverage is uneven, but a national surface exists where none did.
Cause lists as data
Daily cause lists are published electronically across the system. That converts a physically posted notice into something a practice can plan around, and into something that can be monitored at scale.
Video conferencing capability
The infrastructure built under Phase II is what allowed courts to continue functioning through the pandemic, at a scale and speed that would have been impossible to procure from scratch.
Aggregate statistics that exist at all
The National Judicial Data Grid made national pendency visible for the first time. It has real limitations, but a debate informed by imperfect national data is better than a debate informed by none.
There is also a design decision worth acknowledging: the programme's use of free and open source software as its base, adopted early and maintained since, which kept licensing costs off a system deployed at thousands of establishments and made a common national application feasible.
Where Data Quality Falters, and Why
Now the honest part. The weaknesses of eCourts data are real, they are consequential for anybody relying on it, and almost all of them trace back to the same root cause: the data is an administrative byproduct produced under time pressure at thousands of independent establishments.
Publication is incomplete and uneven
Not every order that is passed is uploaded. Interim and procedural orders in particular are inconsistently published, and practice varies between establishments, between States and over time. The absence of an order from the portal establishes nothing about whether the order exists.
Publication is late, unpredictably
An order pronounced today may appear tomorrow, next week, or considerably later. Lag varies by court, by bench and by season. For anything with a limitation consequence, this is not a minor irritation. It is a reason never to compute a deadline from an upload date.
Metadata is hand-entered and therefore variable
Party names, case types, act and section tags, judge names and disposal reasons are entered by staff. The same company appears under several spellings. The same statute is tagged in several ways. Honorifics get concatenated into names. None of this is negligence, it is what data entry at scale looks like, and any faithful mirror of the record inherits it.
Formats vary and extraction quality follows
Some orders are searchable text. Some are scanned images of varying quality. Some are digitally signed documents with their own quirks. Where the source is a poor scan, every downstream process, including search, inherits the poverty of the input.
Taxonomies are local
Case type codes in the district judiciary derive from State practice. The same substantive dispute carries different type descriptions in different States. National analysis by category is therefore harder than a dashboard makes it look, and comparisons across States need a mapping that somebody has to build by hand.
Search interfaces are built for lookup, not for research
The public search forms are designed for somebody who knows what they are looking for: a case number, a party name, a CNR. They are not designed for the research question, which is what has been decided on facts like these. That is a design choice appropriate to the system's purpose, and it is why an entire layer of tooling exists above it.
The absence of a record is not a record of absence
This is the most important operational consequence of everything above. If a search of eCourts surfaces returns nothing against a party or a matter, you have learned that nothing was found. You have not learned that nothing exists. It may not have been uploaded, it may be tagged under a spelling you did not try, or it may sit in a forum outside the system. Anybody who writes a nil result into a diligence report as a clean chit is making a professional error, not a factual finding.
What Phase Three Is Trying to Change
Phase III, approved in 2023 with a substantially larger outlay than its predecessors, is framed around a different idea. The first two phases digitised an existing paper process. The third is meant to design for digital from the start.
- Digitisation of legacy records. Converting the historical paper record into digital form, which is the precondition for anything resembling complete coverage of older matters.
- A unified technology platform. Reducing the number of separate systems a user has to touch, and making data flow between the judiciary and the agencies it interacts with rather than being re-entered.
- Paperless courts and expanded e-filing. Moving filing and record keeping to digital as the default rather than as an option exercised by the willing.
- Expanded virtual and hybrid capability. Building on what was assembled at speed during the pandemic, with the intention of making it a designed capability rather than an emergency one.
- Online dispute resolution. Routing suitable categories of dispute away from court proceedings entirely.
- Better citizen-facing services. Including service delivery through intermediaries for litigants without direct digital access, which matters enormously in a country where the digital divide tracks the justice divide.
The honest assessment of Phase III is that its ambition is correct and its difficulty is far greater than the earlier phases. Digitising a register is an engineering and procurement problem. Redesigning a filing process, changing what staff at thousands of establishments do every day, and getting a bar accustomed to paper to work differently is an institutional change problem. Those fail more often than they succeed, and they fail slowly and quietly.
Phase one and two automated the process the courts already had. Phase three asks the courts to work differently. Those are not the same kind of project, and they do not carry the same risk.
What This Means If You Rely on the Data
For a practitioner, a researcher or anybody building on this data, the right posture is neither dismissal nor trust. It is calibrated use, with a few habits that carry most of the weight.
Treat status data as indicative and dispositive data as verifiable
A next date pulled from a portal is good enough to plan around. It is not good enough to stake a limitation computation on. Anything that decides a right gets verified against the record of the court that issued it.
Use the CNR wherever it exists
Case numbers change on transfer and renumbering, and party names are unreliable handles. The CNR is the most stable identifier available and is the right key for tracking a matter over time.
Search names as a family, not as a string
Because entry is manual, run every plausible variant: with and without the corporate suffix, with and without initials, common transliterations, former names, and the misspellings a hurried typist would produce.
Re-run searches instead of trusting a snapshot
Because publication is late, a search today can return matters that were pending but invisible last month. On a live exposure, the search is a standing question rather than a one-time event.
Record coverage in the output
State in your note or report which forums were searched, which name variants were used, and the date. It protects the client, who then knows what the search establishes, and it protects you.
The pipes are the achievement. The value is downstream.
The eCourts programme's real accomplishment is that a national, machine-readable record of Indian litigation exists at all, produced continuously by the courts themselves. What it did not attempt, and was never designed to attempt, is the research layer: retrieval by issue rather than by identifier, reconciliation of a party across forums, and detection of divergence between benches. That gap is not a failure of the programme. It is the space the programme created.
What Gets Built on Top
This is where our own position should be stated plainly rather than smuggled in. CourtMesh exists because official publication solved availability and left retrieval untouched. It runs one search across the Supreme Court, all twenty-five High Courts, the district judiciary and tribunals including NCLT, NCLAT, ITAT and CESTAT, sourced only from official government portals, with roughly 310 million records keyword-searchable and roughly 2 million carrying deeper semantic indexing so that a question can be asked by issue rather than by keyword.
None of that manufactures data the courts did not publish. If an order was never uploaded, no aggregator has it. If a name was entered wrongly at source, a faithful index inherits the error. What changes is the cost of asking a question across the whole system at once, and the ability to ask questions the official search forms were never built to answer.
The fair summary is that eCourts is the reason it is now possible to be usefully critical about Indian judicial data. Two decades ago the criticism would have been that there was no data. The programme built the pipes, at national scale, on a shoestring relative to what comparable systems cost elsewhere, and it did so while the courts kept running. What comes next is a question about what gets built on top, and about whether Phase III's harder ambition survives contact with institutional reality.
Search everything eCourts publishes, in one place
The official surfaces solved availability. Finding what you need across them is still a dozen searches in a dozen grammars. CourtMesh puts the Supreme Court, all twenty-five High Courts, the district judiciary and tribunals including NCLT, NCLAT, ITAT and CESTAT behind one unified search, drawn only from official government portals, with filters for court, judge, year, case type and date range. Ask once, see where the answer came from, and verify it against the issuing court's record.
Explore CourtMesh
