Service continuity is one of the most important legal and commercial issues for technology startups.

A startup may provide:

• SaaS software,
• cloud infrastructure,
• payment technology,
• online marketplaces,
• mobile applications,
• subscription services,
• artificial intelligence tools,
• cybersecurity services,
• logistics platforms,
• reservation systems,
• e-commerce infrastructure,
• digital marketing services,
• or API-based technology.

In most of these business models, customers expect the service to function continuously and in accordance with the promises made by the startup.

But what happens if the service fails?

For example:

• a SaaS platform becomes unavailable for twelve hours;
• an e-commerce startup loses customer orders because of a system failure;
• an API stops working and prevents a corporate customer from processing transactions;
• a payment system experiences an outage;
• a cloud-based platform accidentally deletes customer data;
• a startup fails to deliver a promised digital service on time;
• an artificial intelligence service repeatedly generates unusable results;
• or a third-party cloud provider suffers a technical failure that interrupts the startup’s own service.

Does every service interruption automatically create compensation liability for the startup?

The answer under Turkish law is no.

A service interruption does not automatically mean that the startup must compensate every loss alleged by the customer.

However, depending on the circumstances, the startup may face significant contractual and consumer-law liability.

The core legal questions generally include:

1. What exactly did the startup promise?
2. Was the service performed in accordance with the contract?
3. Was the interruption attributable to the startup?
4. Can the startup prove that no fault can be attributed to it?
5. Did the customer actually suffer legally compensable damage?
6. Is there an adequate causal connection between the breach and the damage?
7. Did the contract contain a valid limitation-of-liability clause?
8. Is the customer a consumer or a commercial enterprise?
9. Was the interruption caused by a third-party provider?
10. Did force majeure or impossibility of performance arise?

Under Article 112 of the Turkish Code of Obligations No. 6098, where an obligation is not performed at all or is not properly performed, the debtor must compensate the creditor’s resulting damage unless the debtor proves that no fault can be attributed to it.

This provision is highly relevant to startups.

If a startup promises to provide a particular digital service but does not perform that obligation properly, compensation liability may arise.

However, the existence and amount of liability require a much more detailed analysis than simply proving that the application was temporarily unavailable.

This article explains startup service interruption liability in Turkey, including SaaS downtime, defective digital services, consumer compensation claims, third-party cloud failures, force majeure, service-level agreements, limitation-of-liability provisions and practical ways startups can manage their contractual risk.

The First Question: What Did the Startup Promise?

The starting point in any service interruption dispute should be the contract.

A court cannot determine whether a service has been improperly performed without first identifying what the startup undertook to provide.

Suppose a startup operates a cloud-based accounting platform.

Its contract states:

“The service will be available 24 hours per day, subject to scheduled maintenance and the Service Level Agreement.”

That promise creates one type of contractual standard.

Now imagine another contract stating:

“The service is provided without a guaranteed availability percentage and may be temporarily interrupted for maintenance, updates, cybersecurity incidents or infrastructure failures.”

The legal analysis may be different.

Therefore, startups should define the service carefully.

Relevant contractual questions include:

• What functionality is promised?
• Is availability guaranteed?
• Is an uptime percentage stated?
• Are maintenance windows excluded?
• Are response times guaranteed?
• Is data backup included?
• Is disaster recovery included?
• Is technical support included?
• Are third-party integrations guaranteed?
• Is the startup providing a result or only reasonable efforts?
• What happens if the service becomes unavailable?

A vague contract creates uncertainty for both parties.

Not Every Technical Problem Is a Contractual Breach

Modern software is rarely completely free from technical problems.

A temporary bug does not necessarily mean that the entire service contract has been breached.

The seriousness of the interruption may depend on:

• its duration;
• frequency;
• affected functionality;
• number of users;
• contractual importance;
• consequences for the customer;
• and whether the startup corrected the problem promptly.

For example, a ten-minute interruption in a non-critical analytics dashboard may be treated very differently from a twelve-hour failure of a payment platform during a major sales event.

The legal analysis should therefore focus on whether the service departed from the contractual standard to a degree constituting non-performance or improper performance.

Turkish Code of Obligations Article 112 Is the Main Contractual Liability Rule

Article 112 of the Turkish Code of Obligations establishes the basic rule for contractual damages.

Where the obligation is not performed or is improperly performed, the debtor is responsible for the resulting damage unless it proves that it cannot be blamed for the breach.

For a startup, this means that a customer claiming contractual damages will generally focus on:

• the contractual obligation;
• the breach;
• the damage;
• and the causal connection.

Once improper performance is established, the startup may need to demonstrate the absence of attributable fault in accordance with the statutory framework.

This can make documentation extremely important.

A startup should be able to show:

• monitoring records;
• incident reports;
• technical logs;
• security measures;
• maintenance procedures;
• third-party communications;
• backup policies;
• and steps taken to prevent or limit the interruption.

What Does “Fault” Mean in a Technology Service?

A startup can potentially be responsible for different degrees of fault.

Examples may include:

Intentional Conduct

The startup deliberately disables a customer’s service contrary to the agreement.

Gross Negligence

The startup ignores an obvious and serious infrastructure risk despite repeated warnings.

Ordinary Negligence

A preventable configuration error causes downtime.

Properly Managed External Event

A genuinely unforeseeable external event causes interruption despite reasonable precautions.

The level of fault matters because contractual attempts to exclude liability are subject to statutory limitations.

Article 114 provides that a debtor is generally responsible for all forms of fault and that the extent of responsibility is determined according to the nature of the transaction.

Can a Startup Exclude All Liability in Its Terms of Use?

Startups frequently include provisions such as:

“The company shall not be liable for any service interruption under any circumstances.”

This type of clause should not automatically be assumed to be enforceable.

Article 115 of the Turkish Code of Obligations provides that a prior agreement excluding liability for gross fault is absolutely invalid.

Therefore, a startup cannot safely design its contract around the idea:

“Even if we act with gross negligence and destroy the customer’s data, we will never be responsible.”

Mandatory legal limits continue to apply.

A better liability clause should distinguish between:

• legally non-excludable liability;
• ordinary negligence;
• indirect damages;
• lost profits;
• liability caps;
• third-party services;
• unsupported uses;
• customer-caused incidents;
• and force majeure.

B2B and B2C Customers Must Be Distinguished

This distinction is fundamental.

A startup may sell the same application to:

• an individual consumer;
• and a large corporation.

The applicable legal framework can differ substantially.

B2B Relationship

Where the customer acts for commercial or professional purposes, the dispute will generally be governed primarily by:

• the Turkish Code of Obligations;
• the Turkish Commercial Code where applicable;
• and the parties’ contract.

B2C Relationship

Where the customer acts for non-commercial and non-professional purposes, Law No. 6502 on Consumer Protection may apply.

Consumer law provides mandatory protections that cannot simply be eliminated through standard Terms of Use.

A startup should therefore determine at onboarding whether its product is:

• B2B only;
• B2C only;
• or mixed B2B/B2C.

When Is a Startup Service “Defective” Under Consumer Law?

Articles 13 to 16 of Law No. 6502 specifically regulate defective services.

Article 13 defines a defective service as a service that:

• does not begin within the period agreed in the contract; or
• fails to possess the characteristics agreed by the parties or objectively required.

The law also treats services as defective where they do not possess characteristics stated by the provider on its website, advertisements or announcements, or where deficiencies reduce or eliminate the value or benefits that the consumer can reasonably expect.

This definition is extremely relevant to digital startups.

Example: SaaS Application Sold to Consumers

Suppose a startup advertises:

“Unlimited cloud storage available 24/7.”

A consumer purchases an annual subscription.

The service repeatedly becomes unavailable and the customer cannot access stored documents for several days each month.

The consumer may argue that the service does not possess the characteristics advertised and that the benefit reasonably expected from the service has been materially reduced.

That situation can qualify as a defective service under Article 13.

Advertising Claims Can Become Legally Important

Startup founders often focus carefully on the contract while allowing the marketing team to make much more aggressive promises.

For example:

Contract:

“Service availability may vary.”

Website:

“Guaranteed 100% uninterrupted availability.”

Advertisement:

“Never lose access to your business again.”

Customer presentation:

“Our system can never go offline.”

These statements can increase legal risk.

Article 13 expressly takes into account characteristics stated through internet portals, advertisements and announcements, while Article 14 requires the provider to perform the service in accordance with the contract.

Marketing and legal documents should therefore be aligned.

What Rights Does a Consumer Have When the Service Is Defective?

Article 15 gives consumers several alternative remedies where a service is defective.

The consumer may request:

• re-performance of the service;
• free repair of the result produced by the service;
• a reduction in price proportionate to the defect;
• or withdrawal from the contract.

The provider must generally comply with the remedy selected by the consumer, subject to the statutory limitations concerning disproportionate difficulty. The consumer may also claim compensation under the Turkish Code of Obligations in addition to exercising one of these rights.

This is crucial.

A refund and a damages claim are not necessarily the same thing.

Refund and Compensation Are Different Remedies

Suppose a consumer pays TRY 5,000 for a digital service.

The service fails completely.

The consumer may seek return of the TRY 5,000 under the relevant consumer remedy.

But suppose the failure also caused an additional legally compensable loss.

The consumer may potentially seek additional damages under the Turkish Code of Obligations if the conditions for compensation are satisfied.

Therefore:

refund ≠ damages

and

price reduction ≠ damages.

They may coexist where the statutory conditions are present.

Consumers Cannot Automatically Claim Any Amount They Choose

The existence of a defective service does not mean the consumer can demand an unlimited amount.

A damages claim still requires legal analysis concerning:

• actual damage;
• causation;
• attribution;
• and the relevant rules determining compensation.

For example, if a consumer pays TRY 500 for a music-streaming subscription that becomes unavailable for two hours, a claim for TRY 5 million in business losses would obviously require serious scrutiny.

The damage must be connected to the breach in a legally meaningful way.

What Types of Damage Can a Business Customer Claim?

B2B service interruption disputes can involve significant amounts.

A corporate customer may claim:

• lost sales;
• lost production;
• additional staffing costs;
• emergency replacement-service costs;
• data recovery costs;
• contractual penalties owed to third parties;
• customer refunds;
• reputational losses;
• or loss of profit.

However, merely asserting a large number is not sufficient.

The customer must establish the existence and amount of legally recoverable damage and the necessary causal link.

The startup may challenge:

• whether the loss actually occurred;
• whether the amount is speculative;
• whether the customer contributed to the loss;
• whether the loss resulted from another event;
• or whether the contract validly limits the relevant category of damages.

Loss of Profit Can Be One of the Largest Startup Risks

Imagine a SaaS startup serves an online retailer.

The SaaS platform fails during Black Friday.

The retailer argues:

“We would have made TRY 20 million in additional sales if your platform had operated.”

The dispute may then focus on difficult questions:

• Were those sales realistically expected?
• What were historical sales figures?
• Were customers actually unable to purchase?
• Did another technical system also fail?
• Could the retailer have used a backup system?
• What would the profit margin have been?
• Did the contract exclude lost profits?

These disputes can become much more financially important than the monthly SaaS subscription fee.

This is why startups should not sign enterprise contracts without reviewing liability exposure.

Service-Level Agreements Are Essential for SaaS Startups

A Service Level Agreement, or SLA, defines measurable service standards.

An SLA may specify:

• uptime percentage;
• response time;
• support availability;
• incident classifications;
• maintenance windows;
• recovery time;
• backup standards;
• response deadlines;
• and remedies.

For example:

Monthly uptime target: 99.9%.

The SLA may then define how uptime is calculated.

Without a calculation method, even a percentage can become disputed.

99.9% Uptime Does Not Mean Zero Downtime

An SLA should clarify:

• measurement period;
• excluded maintenance;
• force majeure;
• customer systems;
• third-party failures;
• scheduled downtime;
• emergency maintenance;
• and measurement methodology.

Suppose the contract says:

99.9% monthly availability.

The parties should know whether:

• planned maintenance counts;
• customer-caused incidents count;
• internet backbone failures count;
• API vendor failures count;
• and partial functionality counts.

Otherwise, the SLA creates a new dispute instead of preventing one.

Service Credits Can Limit Commercial Conflict

SaaS agreements frequently use service credits.

For example:

Availability below 99.9% → 5% credit.

Availability below 99.5% → 10% credit.

Availability below 99% → 25% credit.

This gives the customer a predictable remedy for ordinary downtime.

A startup may also attempt to specify that service credits constitute the customer’s exclusive contractual remedy for defined availability failures.

However, whether such a clause fully excludes additional liability will depend on:

• the parties’ status;
• mandatory law;
• the wording;
• seriousness of the breach;
• and fault.

In particular, Article 115 prevents advance exclusion of liability for gross fault.

Consumer contracts require even greater caution because mandatory consumer protections cannot simply be eliminated.

Service Credits Should Not Be Confused With Penalty Clauses

A service credit usually operates as a contractual price adjustment or predetermined remedy.

A penalty clause can have different legal consequences.

The contract should clearly define:

• why the payment arises;
• whether actual damage must be proven;
• whether other damages remain available;
• and whether the amount is capped.

Using inconsistent terms such as:

• penalty,
• refund,
• credit,
• compensation,
• liquidated damages

interchangeably can create unnecessary interpretation disputes.

Can a Startup Limit Liability to the Fees Paid by the Customer?

B2B SaaS contracts often contain clauses such as:

“The startup’s aggregate liability shall not exceed the fees paid by the customer during the preceding twelve months.”

This can be an important risk-control mechanism.

However, the enforceability of a liability cap cannot be evaluated independently from Turkish mandatory law.

Article 115 prevents advance exclusion of gross-fault liability.

Accordingly, a liability cap should be drafted with appropriate carve-outs.

For example, parties may separately address:

• intentional misconduct;
• gross negligence;
• confidentiality breaches;
• intellectual property infringement;
• personal data breaches;
• and other risks.

The exact structure should reflect the bargaining position and applicable mandatory rules.

Consumer Contracts Require Additional Caution With Liability Exclusions

A startup should be particularly careful when using standard Terms of Use with consumers.

Law No. 6502 contains protections against unfair contractual terms.

A startup should not assume it can state:

“The consumer waives all rights arising from defective services.”

and thereby eliminate Article 15 remedies.

Consumer law specifically grants rights where the service is defective, including the possibility of claiming damages under the Turkish Code of Obligations.

Terms of Use should therefore be designed around mandatory consumer rights rather than attempting to cancel them.

What If the Service Failure Is Caused by the Startup’s Employee?

A startup may argue:

“The outage was caused by one developer’s mistake, not by the company.”

That does not automatically eliminate liability.

Article 116 of the Turkish Code of Obligations regulates responsibility for persons used in the performance of contractual obligations.

The debtor can be required to compensate damage caused to the other party by assistants used in performing the obligation.

For example:

A DevOps employee accidentally deletes the production database.

The customer contracted with the startup, not personally with the DevOps employee.

The startup cannot ordinarily shift all responsibility to the individual employee simply because the immediate technical error was committed by that person.

What If the Outage Is Caused by AWS, Azure or Another Cloud Provider?

This is one of the most important questions for modern startups.

Suppose:

Customer → Startup → Cloud Provider.

The startup’s platform fails because the cloud provider suffers an outage.

Can the startup simply say:

“It was AWS, so we are not responsible”?

Not necessarily.

The customer contracted with the startup.

The startup’s contractual obligations must be analysed separately from the startup’s rights against its infrastructure provider.

The legal structure may involve two distinct relationships:

Customer ↔ Startup

and

Startup ↔ Cloud Provider.

Whether the startup is liable to the customer will depend on:

• the customer contract;
• the allocation of third-party infrastructure risk;
• the nature of the interruption;
• applicable fault rules;
• force majeure provisions;
• and mandatory law.

The startup may then have a separate recourse claim against the cloud provider if the upstream agreement permits it.

Upstream and Downstream Liability Should Be Matched

This is a major startup-contracting problem.

Suppose the startup promises its enterprise customer:

99.999% availability and unlimited damages for outages.

Its cloud provider contract says:

99.9% availability with liability capped at one month’s fees.

The startup has created a potentially enormous liability gap.

If the infrastructure fails, the startup may owe millions to its customer while recovering very little from the supplier.

Enterprise startups should therefore compare:

Downstream Commitments

What the startup promises customers.

Upstream Protection

What the startup receives from:

• cloud providers;
• payment processors;
• AI providers;
• data centres;
• subcontractors;
• and other vendors.

The two should be commercially aligned.

Third-Party Dependency Should Be Disclosed Clearly

Where service functionality materially depends on external systems, contracts may identify those dependencies.

For example:

• cloud hosting;
• payment networks;
• telecommunications;
• mapping APIs;
• banking systems;
• identity verification providers;
• AI APIs;
• and app stores.

This does not automatically eliminate startup liability.

But transparent allocation of responsibility can reduce uncertainty in B2B contracts.

What If Performance Becomes Impossible Without the Startup’s Fault?

Article 136 of the Turkish Code of Obligations regulates impossibility of performance for reasons for which the debtor cannot be held responsible.

Where performance becomes impossible for reasons not attributable to the debtor, the obligation ends.

In reciprocal contracts, a debtor released because of impossibility must generally return what it has already received under unjust enrichment rules and loses the right to claim the counter-performance that has not yet been rendered. The debtor must also promptly notify the creditor of the impossibility and take necessary measures to prevent the damage from increasing; otherwise it can be liable for additional damage caused by failure to do so.

This provision is important in genuine impossibility cases.

However, every technical difficulty is not legal impossibility.

“The Server Crashed” Is Not Automatically Force Majeure

Technology companies sometimes label every operational problem as force majeure.

Examples include:

• coding mistakes;
• insufficient capacity;
• expired certificates;
• forgotten renewals;
• inadequate backups;
• poor cybersecurity;
• or ordinary vendor outages.

These events should not automatically be assumed to excuse performance.

The legal analysis depends on:

• cause of the event;
• foreseeability;
• preventability;
• contractual risk allocation;
• and whether the startup could reasonably have taken precautions.

A startup cannot generally convert an ordinary operational risk into force majeure simply by calling it force majeure in an incident report.

What Events May Be Treated Differently?

Depending on the contract and circumstances, more extraordinary events may include:

• major natural disasters;
• war;
• government prohibitions;
• widespread infrastructure failures;
• extraordinary telecommunications failures;
• or other events genuinely outside the party’s control.

Even then, the contract should regulate:

• notification;
• mitigation;
• suspension;
• maximum duration;
• and termination rights.

A force majeure clause should not merely list twenty events and stop there.

Cyberattacks Require a Fact-Specific Analysis

Suppose a startup is hit by ransomware.

Is that force majeure?

There is no universal answer.

Questions may include:

• Were reasonable cybersecurity controls implemented?
• Was multi-factor authentication enabled?
• Were known vulnerabilities patched?
• Was the attack unusually sophisticated?
• Were backups maintained?
• Was the startup already warned about the vulnerability?
• Did an employee ignore security procedures?

A cyberattack does not automatically mean the startup was faultless.

If the damage was facilitated by serious security failures, liability may still arise.

Data Loss Can Create Much Greater Liability Than Temporary Downtime

Not all service failures are equal.

A platform being offline for one hour may create limited damage.

Permanent deletion of customer data may create far more significant consequences.

A startup providing data-hosting functionality should clearly define:

• whether backups are included;
• backup frequency;
• retention period;
• recovery points;
• disaster recovery;
• customer backup responsibilities;
• and restoration procedures.

The phrase:

“We back up your data”

is not sufficiently precise for a mission-critical enterprise service.

Recovery Point and Recovery Time Should Be Defined

Technical contracts may use concepts such as:

Recovery Point Objective – RPO

How much recent data may potentially be lost when restoration occurs?

Recovery Time Objective – RTO

How quickly is the service expected to be restored?

These technical metrics can have legal consequences when incorporated into the contract.

If a startup guarantees:

RPO: 15 minutes

but can only restore a backup from three days earlier, contractual liability risk increases.

Customer Responsibilities Should Also Be Defined

A startup should not assume responsibility for problems actually caused by the customer.

Examples include:

• customer misconfiguration;
• compromised customer credentials;
• unauthorised plugins;
• incorrect data;
• unsupported integrations;
• failure to install required updates;
• excessive usage;
• or customer network failures.

A well-drafted agreement should define:

• startup responsibilities;
• customer responsibilities;
• shared responsibilities.

This is especially important in cloud and cybersecurity services.

Customer Contributory Conduct Can Affect the Dispute

Suppose the startup warns the customer:

“Your API key has been compromised. Replace it immediately.”

The customer ignores the warning for three weeks.

A later incident causes losses.

The customer’s own conduct may become relevant to:

• causation;
• mitigation;
• and the amount of recoverable damages.

Customers generally cannot allow damage to increase unnecessarily and then automatically transfer every consequence to the service provider.

For this reason, incident communications should be preserved.

Delay Can Also Create Compensation Liability

Service disruption does not always mean complete unavailability.

A startup may simply perform too late.

For example:

• software implementation promised for 1 June is delivered on 1 September;
• a migration takes three months longer than agreed;
• an API integration deadline is missed;
• or support fails to respond within a contractually guaranteed time.

Article 117 regulates debtor default and provides that a debtor of a due obligation generally falls into default upon notice from the creditor, while specific due dates can create default under the statutory circumstances without a separate notice. Article 118 provides that a debtor in default must compensate damage arising from late performance unless it proves absence of fault in falling into default.

Therefore, service-delay disputes may create separate delay damages even where the service is eventually performed.

Should Implementation Deadlines Be “Hard” or “Estimated”?

Startups should distinguish:

binding delivery dates

from

estimated project timelines.

For example:

“Production launch shall occur no later than 1 October.”

creates a different contractual expectation from:

“The parties currently estimate a production launch around October, subject to completion of customer integrations.”

Where the customer controls part of implementation, the contract should explain how customer delay affects the schedule.

Change Requests Should Be Documented

Software projects frequently expand after the original contract.

The customer requests:

• new functionality;
• additional APIs;
• extra reporting;
• new languages;
• mobile support;
• custom integrations.

The original deadline then becomes impossible.

If the parties do not document the change, the customer may later claim that the startup simply failed to meet the original date.

A formal change request procedure should therefore determine:

• scope change;
• additional fees;
• revised schedule;
• dependencies;
• and approval.

Can the Startup Terminate the Customer’s Service?

Sometimes interruptions are intentional.

For example, the startup may suspend an account because:

• invoices were not paid;
• fraud was detected;
• cybersecurity risk arose;
• prohibited conduct occurred;
• or the customer exceeded contractual usage limits.

The User Agreement or SaaS contract should state when suspension is permitted.

A startup that improperly disables a customer’s critical system without contractual justification can create its own breach.

Suspension clauses should therefore distinguish:

• emergency suspension;
• payment suspension;
• security suspension;
• legal compliance suspension;
• and ordinary termination.

Emergency Cybersecurity Suspension Should Be Addressed

Suppose a customer account appears compromised.

The startup immediately suspends it to prevent data theft.

The customer later complains that the service was unavailable.

A properly drafted agreement should authorise proportionate emergency measures where necessary to protect:

• systems;
• personal data;
• other customers;
• or network security.

This reduces uncertainty during urgent incidents.

Does a Startup Have to Guarantee Uninterrupted Service?

Not automatically.

The required service level depends on:

• contract;
• marketing;
• statutory requirements;
• and nature of the service.

Many technology contracts appropriately acknowledge that absolute uninterrupted availability cannot be guaranteed.

However, a startup should avoid contradictory claims.

It should not say:

Marketing: “Zero downtime guaranteed.”

Contract: “We make no commitment that the service will ever function.”

The entire commercial relationship may be relevant when determining what was promised.

Beta Services Should Be Clearly Identified

Early-stage startups often offer beta products.

If the service is genuinely experimental, the agreement should state:

• beta status;
• expected instability;
• possible feature changes;
• data handling;
• availability limitations;
• and whether production use is recommended.

A startup should not market a system as enterprise-grade and later argue that customers should have known it was an experimental beta.

Free Services Can Still Create Legal Risk

The absence of a subscription fee does not necessarily eliminate all liability.

A free platform may still:

• process customer data;
• make contractual promises;
• cause property loss;
• or create other legal obligations.

However, the nature of the gratuitous transaction may affect how responsibility is evaluated in particular circumstances.

Startups should therefore avoid assuming:

“No customer paid us, so we can never be liable.”

AI-as-a-Service Creates New Service Failure Questions

Artificial intelligence startups create particularly complex performance expectations.

Suppose an AI startup promises:

“Automated invoice extraction with 99% accuracy.”

Actual accuracy is 70%.

Is that merely an ordinary limitation of AI, or a contractual defect?

The answer depends heavily on how the product was represented.

AI contracts should clearly address:

• probabilistic outputs;
• hallucinations;
• human review;
• supported use cases;
• accuracy metrics;
• prohibited reliance;
• and customer responsibilities.

A general statement such as:

“AI can make mistakes”

will not necessarily neutralise specific contractual guarantees.

Financial and Healthcare Services Require Additional Caution

Where a startup operates in regulated sectors, service interruption can trigger rules beyond ordinary contract law.

Examples include:

• banking;
• payment services;
• electronic money;
• healthcare;
• telecommunications;
• insurance;
• and critical infrastructure.

In such sectors, applicable legislation may impose:

• business continuity;
• incident reporting;
• service availability;
• cybersecurity;
• backup;
• or outsourcing requirements.

Therefore, the general Turkish Code of Obligations analysis may only be the first layer.

Personal Data Breaches Can Create Separate Liability

A service interruption may also involve personal data.

For example:

• customer data are deleted;
• data become publicly accessible;
• ransomware blocks access;
• backups are compromised.

This may create issues under Law No. 6698 in addition to contractual liability.

The company may therefore simultaneously face:

• customer contractual claims;
• consumer claims;
• KVKK regulatory obligations;
• cybersecurity costs;
• and reputational damage.

This is why incident response must involve both technical and legal teams.

What Should a SaaS Liability Clause Cover?

A well-drafted SaaS agreement may address:

Service Description

Exactly what is supplied?

Availability

Is there an SLA?

Maintenance

When may scheduled maintenance occur?

Customer Dependencies

Which systems must the customer provide?

Third-Party Infrastructure

Which external dependencies exist?

Data Backup

Who is responsible?

Disaster Recovery

What restoration commitments exist?

Security Incidents

How are incidents handled?

Service Credits

What happens after ordinary downtime?

Direct Damages

Which losses remain recoverable?

Indirect or Consequential Losses

Are they limited where legally permissible?

Lost Profits

How are they treated?

Liability Cap

What aggregate cap applies?

Carve-Outs

Which categories are excluded from the cap?

Force Majeure

What events qualify?

Notification

How quickly must the parties communicate?

Mitigation

What must each party do to reduce damage?

Termination

When does persistent service failure permit termination?

These provisions should operate together rather than contradict each other.

Startup Example: Minor Service Interruption

Startup A provides project-management software.

Monthly fee: TRY 2,000.

The service becomes unavailable for twenty minutes at 03:00.

The contract permits scheduled and emergency maintenance and contains no specific uninterrupted availability guarantee.

No customer data are lost.

The customer suffers no demonstrable financial damage.

The existence of the interruption alone would not necessarily mean the customer automatically has a major damages claim.

The contract and actual loss must be examined.

Startup Example: Serious Contractual Failure

Startup B provides mission-critical payment infrastructure.

The enterprise contract guarantees:

• 99.99% availability;
• redundant infrastructure;
• continuous backup;
• and disaster recovery.

The startup knowingly disables redundancy to reduce costs.

A server failure then causes:

• eighteen hours of downtime;
• data loss;
• and significant customer losses.

The startup may face a much more serious contractual liability argument.

A broad disclaimer is unlikely to provide unlimited protection, particularly where gross fault is established because Article 115 prohibits advance exclusion of liability for gross fault.

Startup Example: Consumer Digital Service

Startup C sells a personal cloud service to consumers.

The website promises:

“Secure access to your files whenever you need them.”

Because of repeated technical failures, customers cannot access documents for several days.

Under Articles 13–15 of Law No. 6502, the service may qualify as defective if it fails to possess contractual or objectively expected characteristics or materially reduces the benefit consumers reasonably expect. Consumers may exercise the statutory remedies and may additionally claim damages under the Turkish Code of Obligations where the conditions are satisfied.

Startup Example: Foreign Cloud Provider Outage

Startup D provides a CRM platform.

Its entire infrastructure is hosted through a foreign cloud company.

The cloud company suffers a regional outage.

The startup’s customers lose access for six hours.

The correct analysis is not simply:

“Cloud provider failed, startup has no liability.”

The parties must examine:

• customer SLA;
• cloud SLA;
• excluded events;
• startup redundancy commitments;
• whether multi-region architecture was promised;
• whether reasonable mitigation was available;
• and whether the startup is entitled to recover anything from its supplier.

This example demonstrates why third-party dependency must be contractually planned.

What Should a Startup Do Immediately After an Outage?

The first hours following a serious outage can significantly affect later liability.

The startup should generally:

1. preserve technical evidence;
2. identify the incident;
3. limit continuing damage;
4. activate backup or recovery systems;
5. communicate accurately with affected customers;
6. avoid unsupported speculation;
7. review contractual notification obligations;
8. determine whether personal data are involved;
9. preserve vendor communications;
10. document decisions;
11. identify root cause;
12. implement corrective measures.

Article 136 itself demonstrates the importance Turkish law places on timely notification and mitigation where performance has become impossible: a debtor that fails to promptly notify the creditor or take measures to prevent increasing damage can be responsible for the resulting additional loss.

Do Not Delete Incident Evidence

After an outage, engineers may immediately want to:

• reset systems;
• rotate logs;
• delete corrupted files;
• or redeploy infrastructure.

Technical recovery may be necessary, but evidence preservation should also be considered.

Potentially important evidence includes:

• server logs;
• access logs;
• monitoring alerts;
• vendor notifications;
• internal messages;
• deployment history;
• code versions;
• database records;
• and customer communications.

These materials may later determine whether the startup can prove that it acted responsibly.

Contractual Liability Checklist for Startups

Before launching a paid digital service, founders should ask:

1. What exactly have we promised customers?
2. Is availability guaranteed?
3. Is an uptime percentage stated?
4. How is uptime calculated?
5. Are maintenance periods excluded?
6. Are third-party failures excluded?
7. Are customer-caused failures excluded?
8. Do we have an SLA?
9. Are service credits available?
10. Are service credits the exclusive remedy for ordinary downtime?
11. Is that exclusive-remedy clause legally permissible for the relevant customer?
12. Is the customer B2B or B2C?
13. Does consumer law apply?
14. Could the service qualify as defective under Article 13?
15. What consumer remedies may apply?
16. Is compensation exposure separately addressed?
17. What liability cap applies?
18. Does the contract attempt to exclude gross negligence?
19. Is the liability clause compatible with Article 115?
20. Are lost profits excluded where legally permissible?
21. Are indirect damages addressed?
22. Who backs up customer data?
23. What is the RPO?
24. What is the RTO?
25. Is disaster recovery tested?
26. Which cloud providers are used?
27. What liability do those providers accept?
28. Is there a liability gap between supplier and customer contracts?
29. Are subcontractors involved?
30. Can Article 116 become relevant?
31. What events qualify as force majeure?
32. Does the force majeure clause require notice?
33. Does it require mitigation?
34. Can prolonged force majeure lead to termination?
35. What happens after a cyberattack?
36. Are data protection obligations triggered?
37. Does sector-specific regulation apply?
38. Are marketing statements consistent with the contract?
39. Are beta products clearly identified?
40. Can the startup prove its compliance if litigation begins?

If these questions cannot be answered, the startup’s contractual liability structure is probably incomplete.

Frequently Asked Questions About Startup Service Failure Liability in Turkey

Does every service outage create compensation liability?

No. The customer must have a legally sustainable claim based on the contract and applicable law. Relevant issues include breach, fault, damage and causation.

What does Article 112 of the Turkish Code of Obligations provide?

Where an obligation is not performed at all or properly, the debtor must compensate resulting damage unless it proves that no fault can be attributed to it.

Can a startup contractually exclude all liability?

Not without limits. In particular, Article 115 provides that an advance agreement excluding liability for gross fault is absolutely invalid.

Can a startup be responsible for an employee’s technical mistake?

Potentially yes. Article 116 regulates contractual liability for persons used in performance of obligations.

Is a startup automatically exempt if AWS or another cloud company caused the outage?

No. The startup’s obligations toward its own customer must be analysed independently from the startup’s contractual relationship with its cloud provider.

Can consumers request compensation for a defective digital service?

Yes, where the conditions are met. Article 15 allows consumers to exercise specified remedies for defective services and also provides that compensation may be claimed under the Turkish Code of Obligations.

What remedies can consumers use for defective services?

They may generally request re-performance, free repair of the result, proportionate reduction of the price or withdrawal from the contract, subject to the statutory rules.

How long is liability for defective consumer services generally subject to limitation?

Unless a longer period is provided by law or contract, Article 16 generally provides a two-year limitation period from performance of the service; the statutory limitation does not apply where the defect has been concealed by gross fault or fraud.

Can service credits replace damages?

They can be used contractually, particularly in B2B SaaS agreements, but whether they completely exclude other remedies depends on contract wording and mandatory law.

Is a cyberattack automatically force majeure?

No. Whether the startup could reasonably have prevented or mitigated the incident must be examined.

What happens if performance becomes genuinely impossible without the startup being responsible?

Article 136 may terminate the obligation in the circumstances regulated by that provision, together with consequences concerning reciprocal performance, repayment, notification and mitigation.

Conclusion: Does a Startup Become Liable for Compensation If Its Service to a Customer Is Disrupted?

A startup does not automatically become liable for compensation every time its website, application, SaaS platform or digital service experiences an interruption.

However, serious service failures can create substantial liability under Turkish law.

The starting point is Article 112 of the Turkish Code of Obligations.

Where an obligation is not performed or is improperly performed, the debtor must compensate the creditor’s resulting damage unless it proves that no fault can be attributed to it.

For a startup, this means the legal analysis should determine:

What service was promised?

Was it properly performed?

Why did it fail?

Was the startup at fault?

What actual damage occurred?

Was that damage caused by the service failure?

The customer’s legal status is also critical.

Where the customer is a business acting for commercial purposes, the parties’ B2B agreement, the Turkish Code of Obligations and, where applicable, commercial law will form the core framework.

Where the customer is a consumer, Law No. 6502 creates additional mandatory protection.

A service that:

• does not begin on time;
• lacks agreed characteristics;
• fails to possess objectively required qualities;
• contradicts characteristics advertised online;
• or materially reduces the benefit reasonably expected by the consumer

may qualify as a defective service under Article 13.

The consumer may then seek:

• re-performance;
• free repair;
• price reduction;
• or withdrawal from the contract,

and may additionally claim compensation under the Turkish Code of Obligations where the necessary conditions are satisfied.

Therefore, startups offering B2C applications should not copy aggressive B2B liability clauses into consumer Terms of Use.

Mandatory consumer rights cannot simply be erased by contract.

For B2B startups, contractual risk allocation becomes particularly important.

A professionally drafted SaaS or technology agreement should define:

• availability;
• uptime;
• scheduled maintenance;
• service credits;
• liability caps;
• third-party infrastructure;
• backup responsibilities;
• disaster recovery;
• data loss;
• force majeure;
• cybersecurity incidents;
• and termination rights.

However, limitation-of-liability clauses have boundaries.

Article 115 expressly provides that an agreement made in advance excluding responsibility for gross fault is invalid.

This means the startup should not attempt to solve every operational risk with one sentence:

“We shall never be liable under any circumstances.”

A sophisticated agreement allocates risk rather than pretending risk does not exist.

Third-party infrastructure also deserves special attention.

A startup that uses AWS, Azure, Google Cloud, an AI API or another SaaS provider should compare what it promises its customers with what the supplier promises the startup.

If the startup promises:

unlimited liability and 99.999% uptime

while its provider offers:

limited service credits and 99.9% uptime,

a major contractual gap exists.

The startup may become the party absorbing the entire difference.

Founders should therefore manage both:

downstream customer contracts

and

upstream vendor contracts

as one risk structure.

Service failure caused by employees and contractors also cannot always be pushed outside the company.

Article 116 specifically regulates responsibility for persons used in performing contractual obligations.

Similarly, a cloud provider outage should not automatically be labelled force majeure.

The factual cause must be examined.

The startup should determine:

• whether the event was foreseeable;
• whether redundancy was promised;
• whether backups existed;
• whether mitigation was possible;
• whether the company ignored known risks;
• and whether the contract actually allocates the relevant external risk.

Where performance becomes genuinely impossible for a reason for which the startup cannot be held responsible, Article 136 may apply. But even then, the startup has duties concerning timely notification and prevention of increasing damage.

This leads to one of the most important practical lessons for technology companies:

Liability is determined not only by what caused the outage, but also by how the startup prepared for it and how it responded after it occurred.

A startup that can demonstrate:

• redundancy;
• security controls;
• tested backups;
• monitoring;
• incident response;
• prompt communication;
• mitigation;
• and properly aligned contracts

will generally have a much stronger legal position than a company that had no operational safeguards and relies only on a disclaimer.

For founders, the correct question is therefore not:

“Can we write a contract saying we are never responsible for downtime?”

The more useful questions are:

What level of availability can we realistically promise?

Which failures are under our control?

Which dependencies belong to third parties?

What level of loss could one serious outage cause?

What liability can our company financially absorb?

What insurance do we have?

What liability do our suppliers accept?

Can our backup architecture actually satisfy our contractual promises?

What consumer rights cannot legally be limited?

These questions should be answered before enterprise customers are signed.

A startup whose monthly revenue from a customer is TRY 100,000 should not accidentally accept uncapped liability for a potential TRY 100 million business interruption without understanding the consequence.

Likewise, a consumer startup should not advertise “guaranteed uninterrupted service” if the actual technical architecture cannot support that promise.

For technology startups operating in Turkey, service continuity is therefore not merely an engineering problem.

It is simultaneously a matter of:

• contract law;
• consumer law;
• cybersecurity;
• vendor management;
• insurance;
• operational resilience;
• and corporate risk management.

The safest legal approach is to connect the contract to technical reality.

The startup should promise only what its infrastructure can realistically deliver, build contractual mechanisms for ordinary failures and preserve appropriate protections for exceptional events.

When these elements are properly structured, an occasional technical interruption does not necessarily become a major damages dispute.

When they are ignored, a single outage can create liability far exceeding the entire value of the service contract.