Edge Computing Service Disputes — Detailed Legal Explanation with at least 6 Case Laws

1. Introduction

Edge computing is a distributed computing model in which data processing occurs closer to the source of data rather than exclusively in a distant central cloud or data centre.

Typical architecture:

Device / Sensor → Edge Node → Regional Edge Facility → Central Cloud

Examples include:

5G and telecom edge computing;

IoT processing;

autonomous vehicles;

smart factories;

smart cities;

retail analytics;

video surveillance;

industrial automation;

healthcare monitoring;

content-delivery services;

AI inference at the network edge;

gaming and low-latency applications.

Because edge computing is usually delivered through a mixture of hardware, software, networking, cloud infrastructure, data centres and managed services, disputes can become legally complex.

There is still limited reported case law specifically labelled as an “edge computing dispute.” Courts therefore analyse such disputes through principles developed in cases concerning:

cloud computing;

IT outsourcing;

service-level agreements (SLAs);

telecommunications infrastructure;

data centres;

managed services;

technology implementation;

system availability and downtime.

2. Nature of an Edge Computing Service Contract

An edge computing agreement may involve obligations concerning:

edge-server deployment;

hardware supply;

software installation;

network connectivity;

latency;

uptime;

data processing;

cybersecurity;

data retention;

cloud integration;

maintenance;

disaster recovery.

A typical contractual promise may state:

“The provider shall operate the edge computing platform with 99.99% availability and average processing latency below 20 milliseconds.”

That single obligation creates several possible disputes.

For example:

What constitutes “availability”?

How is latency measured?

Are planned maintenance periods excluded?

Does a telecom outage count against the provider?

Is the latency measured at the device, edge node or central server?

What remedy follows an SLA breach?

3. Major Categories of Edge Computing Service Disputes

A. Latency disputes

The customer claims that processing did not occur within the agreed time.

Example:

Contractual latency: 10 milliseconds
Actual latency: 45 milliseconds.

The provider may argue that the delay resulted from:

customer network configuration;

third-party connectivity;

device limitations;

extraordinary traffic;

force majeure.

B. Uptime and availability disputes

The edge node may experience:

server failure;

power interruption;

network outage;

software malfunction;

cyberattack.

The main issue becomes:

Did the provider fail the contractual availability threshold?

C. Capacity disputes

A provider may promise:

10,000 transactions per second;

5 petabytes of edge storage;

specified GPU capacity;

a defined number of processing nodes.

The dispute concerns whether the promised capacity was actually made available.

D. Data-loss disputes

The edge system may:

fail to synchronise with the cloud;

overwrite data;

lose locally processed data;

transmit corrupted information.

E. Security disputes

An edge node may be compromised because edge infrastructure is often geographically distributed and physically accessible.

The customer may claim:

“The provider failed to maintain the agreed security controls.”

F. Integration disputes

The edge platform may fail to integrate with:

IoT devices;

ERP systems;

cloud platforms;

5G networks;

AI applications.

4. Case Law 1 — Videocon Telecommunications Ltd. v. IBM India Pvt. Ltd.

Delhi High Court, 2018

This is one of the most important Indian technology-services disputes relevant by analogy to edge computing.

The agreement concerned the supply, installation, commissioning, integration, maintenance and operation of IT systems for a GSM telecommunications network. The arbitration involved major disputes concerning service performance and financial claims. (Indian Kanoon)

The dispute involved claims for:

annual service charges;

project service charges;

alleged service defaults;

damages;

refund claims.

The Delhi High Court's consideration of the arbitral award demonstrates the complexity of technology contracts combining infrastructure, integration, operations and continuing service obligations. (Indian Kanoon)

Application to edge computing

Edge computing has a similar hybrid structure:

hardware + software + network + integration + managed operations

Therefore, a customer cannot always isolate a single component and simply allege “service failure.” The tribunal must determine:

what exact obligation existed;

which component failed;

whether that failure was attributable to the provider;

whether it caused recoverable loss.

Key lesson

Complex technology systems require precise allocation of responsibility between the parties.

5. Case Law 2 — Tata Teleservices Ltd. v. GTL Infrastructure Ltd.

Delhi High Court, 2016

This case is particularly important for uptime-based disputes.

The parties' agreements required the infrastructure provider to maintain a specified percentage of uptime. Where an outage occurred and the agreed uptime level was not maintained, the customer was contractually entitled to make deductions or apply outage penalties. (Indian Kanoon)

Why it is directly relevant to edge computing

An edge computing SLA may state:

99.95% availability per month.

The same legal questions arise:

How is downtime measured?

What equipment is included?

Are scheduled maintenance periods excluded?

Are third-party outages excluded?

Can the customer automatically deduct SLA penalties?

Example

If a contract requires 99.99% monthly uptime, the parties must determine:

What is the maximum permissible downtime?

Without a precise calculation methodology, disputes are inevitable.

Key principle

An SLA must define not merely the percentage but also the methodology for calculating it.

6. Case Law 3 — EIT Services India Pvt. Ltd. v. India Post Payments Bank Ltd.

Delhi High Court, 2023

This case involved a major technology-services project governed by:

an RFP;

a Master Services Agreement;

a Service Level Agreement;

service-level requirements;

project milestones;

a performance bank guarantee.

The dispute concerned alleged material breaches, non-performance and failure to achieve contractual milestones. (Indian Kanoon)

Edge-computing relevance

Large edge deployments frequently have phased milestones such as:

Phase 1 → 100 edge nodes
Phase 2 → 500 edge nodes
Phase 3 → nationwide deployment.

A dispute may arise where:

hardware is supplied but not commissioned;

software is installed but not integrated;

nodes are operational but fail SLA testing.

Key lesson

The contract should distinguish:

deployment completion

from

successful commissioning

and

achievement of SLA performance.

These are legally different milestones.

7. Case Law 4 — M/s Orange Business Services India Pvt. Ltd. v. Central Coalfields Ltd.

Jharkhand High Court, 2024

This dispute involved server-related technology services and allegations that services were discontinued, causing disruption to important business functions. The case also distinguished between technical performance certification and full compliance with commercial contractual obligations. (Indian Kanoon)

Why this matters for edge computing

Suppose an edge provider receives a monthly:

“Satisfactory Performance Certificate.”

Later, the customer discovers:

commercial payment defaults;

security failures;

missing contractual documentation;

data-retention violations.

The provider may argue:

“The customer accepted our performance.”

The customer may respond:

“Technical acceptance did not waive other contractual rights.”

Key principle

Operational acceptance does not necessarily mean complete contractual discharge.

8. Case Law 5 — Pi Data Centers Pvt. Ltd. v. Hewlett Packard Enterprise Co.

U.S. Court of Appeals for the Fifth Circuit, 2025

This dispute arose from a cloud computing and data-services project involving an Indian data-services company, HPE's Indian operations and a local contractual partner. The project experienced significant commercial difficulties, followed by litigation concerning the alleged obligations and conduct of the parties. The appellate court affirmed dismissal of claims against HPE for negligence, negligent misrepresentation and breach of fiduciary duty. (Justia Law)

Relevance to edge computing

Edge computing frequently involves a complex contractual ecosystem:

Customer → systems integrator → edge infrastructure provider → cloud provider → hardware manufacturer.

A dispute may arise where the customer attempts to hold a parent company or upstream technology company liable for the acts of a local contracting entity.

Key lesson

Contractual privity remains critical.

A party should carefully identify:

who signed the contract;

who supplied the infrastructure;

who gave the technical warranty;

who accepted liability.

9. Case Law 6 — Raskspace US Inc. v. DCIT (IT), Mumbai

Income Tax Appellate Tribunal, 2019

The case concerned cloud-hosting services provided under a master services agreement and SLA. The tribunal examined the nature of the arrangement and emphasised that the customer received a managed hosting service rather than possession or control of the underlying servers and equipment. (Indian Kanoon)

Importance for edge computing

This distinction is crucial.

An edge customer may have:

A service right

“Provider shall make edge processing capacity available.”

Or:

A control/possession right

“Customer shall have exclusive control over dedicated edge hardware.”

These are legally and commercially different arrangements.

Key lesson

An edge agreement should clearly state whether it is:

managed service;

equipment lease;

dedicated infrastructure service;

co-location arrangement;

platform service.

10. Case Law 7 — Union of India v. Tech Mahindra Ltd.

Delhi High Court

This technology-services dispute concerned the implementation of a project and disputes relating to SLA methodology and deductions. The court noted that vague allegations of defects, without identifying the nature of the alleged defects and their actual impact on services, were insufficient to justify deductions. (CaseMine)

Relevance to edge computing

A customer should not simply state:

“The edge platform was defective.”

It should identify:

which node failed;

when;

for how long;

what SLA metric was breached;

how the breach was measured;

what contractual remedy applies.

Key principle

Technical breach claims must be evidenced with technical specificity.

This is extremely important in arbitration.

11. Case Law 8 — Character Technologies, Inc. v. Applied Digital Corporation

U.S. District Court, Delaware, 2026

This recent dispute concerns an AI-computing infrastructure arrangement involving access to a specified number of GPUs through data-centre infrastructure. The parties' dispute centred on contractual obligations under an SLA relating to the staged availability of substantial computing capacity. (Justia Law)

Edge-computing relevance

Although the dispute concerns high-performance AI infrastructure rather than conventional edge nodes, the contractual problem is closely analogous:

Was the promised computing capacity actually available when and in the quantity contractually required?

Edge providers increasingly promise:

CPU capacity;

GPU capacity;

inference capacity;

regional processing capacity.

Key lesson

A contract should define “available capacity” precisely. For example:

powered on?

network accessible?

fully operational?

meeting latency requirements?

usable by the customer's application?

12. Case Law 9 — Thoughtsol Infotech Pvt. Ltd. v. Union of India

Allahabad High Court, 2025

This case concerned a government procurement for cloud services relating to the National Data Repository. The dispute concerned the award process and technical qualification in a technology procurement setting. (Indian Kanoon)

Relevance to edge computing procurement

Government edge-computing projects may involve:

smart cities;

defence;

transportation;

public safety;

national data systems.

Disputes may concern:

tender eligibility;

technical qualifications;

price;

public-procurement rules;

preference policies.

Key lesson

Pre-contract procurement disputes can be as important as post-deployment service disputes.

13. Case Law 10 — Amazon Internet Services Pvt. Ltd. v. Commissioner of CGST, Delhi East

CESTAT, 2026

This case concerned data-hosting services provided in connection with cloud computing. The tribunal discussed the role of a data-hosting provider that manages data-centre infrastructure, including operations, infrastructure monitoring, IT management and equipment maintenance. It treated the hosting relationship as a principal-to-principal provision of services rather than an intermediary relationship in the circumstances discussed. (Indian Kanoon)

Edge-computing relevance

The decision helps clarify the operational nature of infrastructure services:

A provider may manage computing infrastructure on behalf of another technology provider without dealing directly with end users.

This is common in edge ecosystems.

For example:

Telecom operator → edge data-centre operator → cloud provider → enterprise customer.

Key lesson

Contracts should clearly define:

service provider;

infrastructure operator;

end customer;

data controller;

processor;

subcontractor.

14. Consolidated Case-Law Table

15. Latency as the Central Edge-Computing Issue

In ordinary cloud computing, the main performance metric may be:

availability.

In edge computing, a central metric is frequently:

latency.

A contract might provide:

“95% of transactions shall be processed with latency below 20 milliseconds.”

However, the contract must specify:

From where is latency measured?

device to edge node?

device to application?

end-to-end?

What percentile applies?

average?

median?

95th percentile?

99th percentile?

Is the measurement continuous?

real time?

hourly?

monthly?

A provider may technically achieve:

15 milliseconds average latency,

while experiencing:

500 milliseconds during critical peak periods.

Therefore, average latency may not be an adequate SLA metric.

16. Uptime Calculation

Suppose an edge SLA states:

99.99% monthly availability.

The contract should specify:

[
Availability = \frac{Total\ Time - Unplanned\ Downtime}{Total\ Time} \times 100
]

But several questions remain:

Is scheduled maintenance excluded?

Is customer-caused downtime excluded?

Are third-party telecom outages excluded?

Is partial service failure downtime?

Is a degraded node “available”?

The Tata Teleservices v. GTL Infrastructure dispute demonstrates the commercial importance of defining uptime and contractual outage penalties. (Indian Kanoon)

17. Distributed Responsibility Problem

Edge computing creates a particularly difficult causation issue.

Example:

Sensor → 5G network → edge node → cloud control plane.

The customer experiences delay.

Who is responsible?

Possible defendants:

device manufacturer;

telecom operator;

edge provider;

cloud provider;

systems integrator.

The contract should therefore include a Responsibility Matrix.

18. Data Synchronisation Disputes

A major edge dispute arises when:

local processing succeeds but cloud synchronisation fails.

Suppose:

edge node processes transactions;

central cloud database is offline;

the local cache becomes corrupted.

The customer may claim:

“The provider lost our data.”

The provider may argue:

“The cloud provider's central system failed.”

The contract should specify:

local retention period;

synchronisation frequency;

replication;

backup;

conflict resolution.

19. Data Ownership

Edge computing can create several categories of data:

Raw device data

Usually customer or end-user data.

Edge-processed data

May contain transformed information.

Telemetry

Provider may generate operational metrics.

Aggregated analytics

May be commercially valuable.

The agreement should define ownership and permitted use of each category.

20. Cybersecurity

Edge nodes can create special security risks because they may be:

geographically distributed;

remotely managed;

physically accessible;

connected to IoT devices.

Common contractual obligations include:

encryption;

secure boot;

patching;

multi-factor authentication;

access logging;

vulnerability management;

incident response.

A security breach can also create an SLA dispute if the provider takes nodes offline to contain the incident.

21. Planned Maintenance

A common dispute concerns whether planned maintenance counts as downtime.

A provider may schedule:

8 hours of maintenance.

The customer argues:

“The service was unavailable.”

The provider argues:

“Scheduled maintenance is excluded.”

The contract should specify:

advance notice;

maximum maintenance hours;

maintenance window;

emergency maintenance;

whether excessive maintenance is counted.

22. Service Credits

A typical SLA might provide:

The crucial legal question is:

Are service credits the customer's exclusive remedy?

If yes, the customer may be prevented from claiming larger damages for ordinary SLA breaches.

The structure of contractual deductions in Tata Teleservices v. GTL Infrastructure is a useful illustration of the importance of clearly agreed SLA remedies. (Indian Kanoon)

23. Failure to Meet Latency SLA

A provider may claim:

“The service remained available, therefore there was no breach.”

But an edge customer may respond:

“Availability is useless if latency exceeds the agreed threshold.”

The contract should therefore treat:

Availability SLA

and

Performance SLA

as separate obligations.

24. Capacity Reservation

An enterprise may reserve:

500 edge GPU units.

The provider may have the physical infrastructure but allocate the capacity elsewhere.

This creates a dispute similar to the issues surrounding promised computing capacity in Character Technologies v. Applied Digital. (Justia Law)

The agreement should define:

“reserved capacity” = capacity exclusively committed and technically available to the customer.

25. Hardware Failure

Suppose an edge server fails.

The provider may offer:

replacement within 48 hours.

But the customer requires:

replacement within 2 hours.

The agreement should contain:

replacement times;

spare inventory;

remote failover;

redundant nodes;

disaster recovery.

26. Termination and Data Exit

An edge customer may become technically dependent upon the provider's:

infrastructure;

APIs;

local storage;

orchestration software.

At termination, the customer needs:

its data;

configuration;

logs;

metadata.

A contract should provide:

export format + delivery period + deletion certification.

Otherwise, the provider may effectively create vendor lock-in.

27. Intellectual Property

The agreement should distinguish between:

Provider IP

edge software;

orchestration tools;

APIs.

Customer IP

applications;

data;

proprietary algorithms.

Joint developments

customised edge configurations;

integration code.

Failure to distinguish these can create disputes after termination.

28. Force Majeure

Potential edge-computing force-majeure events include:

natural disasters;

major power-grid failures;

war;

government shutdowns;

widespread telecommunications failures.

However, the provider should not be able to classify:

ordinary equipment failure

or:

inadequate redundancy

as force majeure.

29. Damages

An edge-computing failure may cause:

lost revenue;

production stoppage;

regulatory penalties;

data recovery costs;

replacement-provider costs;

customer claims.

Under Indian law, damages for breach of contract are generally analysed through the Indian Contract Act, 1872, particularly Section 73.

The claimant must ordinarily establish:

breach;

causation;

loss;

recoverability.

In a technology dispute, expert evidence is often essential.

30. Limitation of Liability

A provider may cap liability at:

fees paid in the previous 12 months.

The customer may seek separate carve-outs for:

confidentiality;

data breach;

IP infringement;

fraud;

wilful misconduct.

A crucial drafting issue is whether:

SLA credits count toward the liability cap.

This should be expressly addressed.

31. Arbitration

Edge-computing disputes are particularly suitable for arbitration because they involve confidential:

architecture;

source code;

performance metrics;

cybersecurity information;

pricing;

customer data.

A useful clause should cover disputes concerning:

“availability, latency, capacity, processing performance, data loss, security, SLA compliance, service credits, maintenance, interoperability, intellectual property and termination.”

32. Expert Determination

For purely technical disputes, the contract may first require:

independent expert determination.

Example:

“A dispute concerning latency measurement shall first be referred to an independent technical expert.”

This can prevent arbitrators from deciding highly technical questions without specialised assistance.

33. Evidence in an Edge Computing Arbitration

Important evidence may include:

server logs;

latency reports;

uptime records;

telemetry;

network logs;

incident tickets;

monitoring dashboards;

API logs;

maintenance notices;

security reports.

The party claiming an SLA breach should preserve original logs and audit trails.

34. Hypothetical Dispute

Assume:

Manufacturer A hires Provider B to operate an edge platform for 500 smart factories.

Contract:

99.99% uptime;

latency below 10 ms;

99.5% data synchronisation;

24/7 support.

After deployment:

latency rises to 80 ms;

20 edge nodes fail;

data synchronisation falls to 95%;

a cyberattack disables local processing.

A claims ₹200 crore in damages.

35. Tribunal's Analysis

Step 1 — Identify contractual obligations

What were B's precise SLAs?

Step 2 — Examine measurement methodology

How were latency and availability calculated?

Step 3 — Identify excluded events

Did force majeure apply?

Step 4 — Determine responsibility

Was the failure caused by:

B's edge platform?

A's factory network?

telecom infrastructure?

a third party?

Step 5 — Assess security obligations

Was the cyberattack caused by contractual non-compliance?

Step 6 — Determine causation

Did the technical failure actually cause the claimed losses?

Step 7 — Apply remedies

service credits;

damages;

termination;

specific data-return obligations.

36. Key Contractual Clauses

A robust edge-computing agreement should include:

1. Service description

Define nodes, regions, hardware and software.

2. Latency SLA

Define measurement point and percentile.

3. Availability SLA

Define downtime and exclusions.

4. Capacity SLA

Define guaranteed resources.

5. Data synchronisation

Define replication and recovery.

6. Security

Define minimum cybersecurity standards.

7. Maintenance

Define permitted downtime.

8. Change control

Define how architecture changes are approved.

9. Service credits

Define automatic remedies.

10. Liability

Allocate financial risk.

11. Data exit

Define return and deletion.

12. Dispute resolution

Use technical experts and arbitration where appropriate.

37. Most Important Legal Lessons

1. Precise technical metrics are essential

Vague promises such as:

“high performance”

or:

“low latency”

create disputes.

2. SLA methodology matters as much as the SLA number

The principles reflected in Union of India v. Tech Mahindra and Tata Teleservices v. GTL Infrastructure show why technical allegations must be tied to an identifiable measurement framework. (CaseMine)

3. Complex technology involves multiple actors

Pi Data Centers v. Hewlett Packard Enterprise demonstrates the importance of identifying the actual contracting and responsible entity. (Justia Law)

4. Technical acceptance does not necessarily settle every dispute

Orange Business Services v. Central Coalfields illustrates the distinction between technical performance acceptance and broader commercial compliance. (Indian Kanoon)

5. Availability and capacity are separate concepts

The provider may have an operational system but still fail to provide promised computing capacity, an issue illustrated by the computing-infrastructure dispute in Character Technologies v. Applied Digital. (Justia Law)

6. Infrastructure service is different from equipment leasing

The Rackspace case demonstrates the legal importance of distinguishing a managed service from a right to possess or control the underlying infrastructure. (Indian Kanoon)

38. Conclusion

Edge computing service disputes are fundamentally hybrid technology-contract disputes. They combine elements of:

cloud computing;

telecommunications;

hardware infrastructure;

managed IT services;

cybersecurity;

data processing;

SLA enforcement.

Because edge computing operates through distributed infrastructure, the central legal difficulty is often attribution of responsibility.

The customer may say:

“The application failed.”

The provider may respond:

“Our edge infrastructure was operational; the problem was caused by the telecom network.”

The real legal question therefore becomes:

Which party contractually assumed responsibility for the component that actually failed?

The most useful authorities include:

Videocon Telecommunications v. IBM India — complex technology-service performance disputes.

Tata Teleservices v. GTL Infrastructure — uptime obligations and SLA penalties.

EIT Services v. India Post Payments Bank — MSA, SLA, milestones and performance security.

Orange Business Services v. Central Coalfields — service disruption and acceptance issues.

Pi Data Centers v. Hewlett Packard Enterprise — contractual privity in cloud/data projects.

Rackspace US Inc. v. DCIT — distinction between managed hosting and control of infrastructure.

Union of India v. Tech Mahindra — requirement for specific proof of technical defects.

Character Technologies v. Applied Digital — disputes over promised computing capacity.

Thoughtsol Infotech v. Union of India — cloud technology procurement.

Amazon Internet Services v. Commissioner of CGST — the contractual and operational role of infrastructure hosting providers.

The strongest edge-computing contract should therefore clearly define:

edge architecture + responsibility matrix + latency metric + uptime calculation + capacity guarantee + maintenance exclusions + data synchronisation + cybersecurity + service credits + liability + exit rights.

Without those provisions, a simple technical failure can become a major dispute involving breach of contract, SLA deductions, consequential damages, data loss, security failures, vendor lock-in and multi-party responsibility.