This chapter covers Google Cloud Platform (GCP) Service Level Agreements (SLAs) and uptime guarantees. It explains what SLAs are, how they work, the specific uptime percentages for key services, and how service credits are calculated. For the GCDL exam, this topic appears in approximately 5-8% of questions, often testing your understanding of the difference between SLA uptime percentages and actual availability guarantees, as well as the conditions under which credits apply. Mastering this material is essential for understanding Google Cloud's commitment to reliability and how to architect for high availability.
Jump to a section
A Service Level Agreement (SLA) is like an insurance policy for cloud uptime. When you buy insurance for your car, you pay a premium, and the insurer promises to pay you if certain bad events happen (accident, theft). But the insurance doesn't prevent the accident—it only compensates you financially after the fact. Similarly, a cloud SLA is a contractual promise from Google that if the service goes down for longer than a defined threshold, you get a credit (like a partial refund) on your bill. The SLA doesn't make the service more reliable; it's a financial backstop. For example, if Compute Engine has a monthly uptime percentage of 99.95% or higher, no credit. If it falls below that, you get a 10% credit. The lower the uptime, the larger the credit, up to 100% for sustained outages. But you must claim the credit within a specified timeframe (usually 30 days) and meet eligibility conditions (like using multiple zones). Just like insurance policies have deductibles and exclusions, SLAs have service credits that only apply to specific services and require you to meet certain requirements (e.g., running instances in multiple zones for zonal SLA). If you don't architect for high availability, you might not qualify for the full credit even if the service is down. So the SLA is a contract, not a guarantee of uptime—you still need to design your application to survive failures.
What is a Service Level Agreement (SLA)?
A Service Level Agreement (SLA) is a contractual commitment between Google Cloud and the customer regarding the level of service expected. It defines metrics such as uptime percentage, response times, and remedies if the service fails to meet those metrics. In cloud computing, the most common SLA metric is uptime, expressed as a percentage of total possible time in a month (e.g., 99.95%, 99.99%). The SLA does not guarantee that the service will be available 100% of the time; instead, it establishes a threshold below which the customer is eligible for service credits—a percentage refund on the monthly bill.
How GCP SLAs Work
Google Cloud publishes SLA documentation for each service. The SLA specifies: - Monthly Uptime Percentage (MUP): Calculated as (Total minutes in month - Downtime minutes) / Total minutes in month × 100. Downtime is defined as a period where the service is unavailable, typically confirmed by Google's monitoring systems. - Service Credit Tiers: For example, for Compute Engine instances (single zone), if MUP < 99.5% but ≥ 99.0%, credit = 10%. If MUP < 99.0%, credit = 25%. For multi-zone instances, thresholds are higher: < 99.99% but ≥ 99.95% → 10%; < 99.95% → 25%; < 95.00% → 50%. - Maximum Credit: Usually capped at 100% of the monthly bill for the affected service, but often limited to 50% for partial outages. - Claim Process: You must submit a credit request within 30 days of the end of the billing month, providing details like project ID, instance names, and outage timestamps. Google reviews and may adjust credits. - Exclusions: Scheduled maintenance (with advance notice), customer actions (e.g., stopping instances), force majeure, beta features, and services used in violation of terms are not covered.
Key Uptime Percentages for Major Services
- Compute Engine: - Single zone: 99.5% uptime (monthly). Multi-zone (using a load balancer across 2+ zones): 99.99% uptime. - VM instance SLA: Only applies if you run instances in at least two zones behind a load balancer. Single instance in one zone: no SLA credit for downtime beyond 5 minutes? Actually, the SLA still applies but with a lower threshold (99.5%). - Cloud Storage: - Multi-regional / Dual-regional: 99.95% uptime (monthly). - Regional: 99.9% uptime. - BigQuery: 99.99% uptime (monthly) for storage and query processing. - Cloud SQL: - Single zone: 99.95% uptime. - High availability (regional): 99.99% uptime. - Google Kubernetes Engine (GKE): - Zonal cluster: 99.5% uptime (for the control plane). - Regional cluster: 99.95% uptime. - Cloud Load Balancing: 99.99% uptime. - Cloud CDN: 99.99% uptime. - Cloud Interconnect: 99.99% uptime (dedicated) or 99.9% (partner). - App Engine: 99.95% uptime for Standard and Flexible environments.
Service Credit Calculation Examples
Suppose you run a single Compute Engine instance in zone us-central1-a for a 30-day month (43,200 minutes). The instance experiences 200 minutes of downtime. MUP = (43,200 - 200) / 43,200 × 100 = 99.54%. Since this is above 99.5%, no credit. If downtime was 300 minutes, MUP = 99.31% (below 99.5% but above 99.0%), so you get a 10% credit on the instance's monthly cost. If downtime was 500 minutes, MUP = 98.84% (below 99.0%), credit = 25%.
Conditions for SLA Eligibility
Multi-zone deployments: For many services (Compute Engine, Cloud SQL), the highest SLA tier (e.g., 99.99%) requires running in at least two zones within a region. If you use only one zone, you get a lower SLA (e.g., 99.5% for Compute Engine).
Load balancing: For Compute Engine SLA, you must use a load balancer that distributes traffic across instances in multiple zones. The load balancer itself has its own SLA (99.99%).
Monitoring: You must use Google Cloud's health checks to detect instance failures. If the instance is down but the health check doesn't detect it (e.g., due to misconfiguration), the downtime may not count towards SLA.
Scheduled maintenance: Google performs periodic maintenance (e.g., host updates) that can cause VM live migration or reboot. This is excluded from downtime if Google provides advance notice (typically 1 week). If the migration fails and causes extended downtime, it may be covered.
How SLAs Interact with Architecture
SLAs influence architectural decisions. To achieve 99.99% uptime for Compute Engine, you must:
Deploy at least two instances across different zones.
Place them behind a load balancer (e.g., HTTP(S) Load Balancer) with health checks.
Ensure each instance can handle the full load if one zone fails.
Use regional persistent disks or replicated storage to survive zone failure.
Similarly, for Cloud SQL, high availability requires a primary and standby instance in different zones with synchronous replication. The failover is automatic, but during failover there may be a brief outage (typically < 60 seconds), which is not counted as downtime if within SLA limits.
SLA Exclusions and Limitations
Beta features: Services or features marked as Beta (pre-GA) are not covered by any SLA.
Customer-caused outages: If you delete a resource, misconfigure firewall rules, or exceed quotas, resulting downtime is not covered.
Third-party dependencies: If a third-party service (e.g., your ISP) causes downtime, Google is not responsible.
Force majeure: Acts of nature, war, terrorism, etc., are excluded.
Maximum credit: Even if downtime is extensive, the total credit is capped at 100% of the monthly fee for that service. You cannot get more than you paid.
Other SLA Metrics
While uptime is the primary metric, some services have additional SLAs: - Latency: For Cloud Load Balancing, 99.99% of requests must complete within 5 seconds. - Throughput: For Cloud Interconnect, committed capacity is guaranteed; if not met, credits apply. - Error rate: For Cloud Storage, less than 0.01% of requests return errors.
SLA vs. Availability Guarantee
The SLA is a financial commitment, not a technical guarantee. Google does not guarantee 100% uptime; it promises to compensate you if uptime falls below a threshold. Therefore, you must still architect for failure: use multiple zones, regions, and retry logic. The SLA is a safety net, not a design blueprint.
How to View SLA Compliance
You can monitor uptime using: - Cloud Monitoring: Create uptime checks that ping your endpoints from multiple locations. These checks are not the same as Google's internal SLA measurement, but they give you visibility. - Google Cloud Console: The SLA page shows historical uptime per service? Actually, there is no central SLA dashboard. You can check service health at status.cloud.google.com. - Billing reports: Credits appear as negative line items on your invoice.
SLA for Free Tier and Trial Accounts
Free tier services (e.g., f1-micro instances) are subject to the same SLA as paid services. However, trial accounts with limited credits may not be eligible for credits if the service is free (since you didn't pay). The SLA applies to the service itself, but credits are only issued against actual charges.
SLA and Multi-Region Deployments
For services like Cloud Storage Multi-Regional, the SLA is 99.95% across the entire multi-region. If a single region fails but data is replicated to other regions, the service may still be available, so no downtime. If the entire multi-region fails (e.g., due to a global outage), credits apply. For Compute Engine, multi-region deployments are not directly supported; you must use load balancing across regions, which adds complexity.
SLA for Serverless Services
Cloud Functions: 99.95% uptime for the service (invocation). Cold starts are not considered downtime.
Cloud Run: 99.95% uptime for the managed service.
App Engine: 99.95% uptime.
These services have automatic scaling and redundancy built in, so achieving high uptime is easier, but you still need to handle errors in your code.
SLA for Networking Services
Cloud Load Balancing: 99.99% uptime for global and regional load balancers.
Cloud NAT: 99.95% uptime.
Cloud VPN: 99.95% uptime for HA VPN (two tunnels).
Cloud Interconnect: 99.99% for dedicated, 99.9% for partner.
SLA for Data and Analytics
BigQuery: 99.99% uptime for storage and query processing. This is very high because BigQuery is a serverless, multi-tenant service with built-in redundancy.
Pub/Sub: 99.95% uptime for the service.
Dataflow: 99.9% uptime for the service (not individual pipelines).
Dataproc: 99.9% uptime for the managed service.
SLA for AI and ML Services
Vertex AI: 99.95% uptime for the platform.
Cloud Vision API: 99.9% uptime.
Cloud Translation API: 99.9% uptime.
These services are typically consumed via APIs, and downtime means API requests fail. Credits are based on the monthly bill for that API.
SLA for Storage
Cloud Storage:
- Multi-regional: 99.95% - Dual-regional: 99.95% - Regional: 99.9% - Nearline: 99.95% (but retrieval fees apply) - Coldline: 99.95% - Archive: 99.95% (but minimum storage duration) - Persistent Disk: 99.95% for zonal, 99.99% for regional (replicated across zones). - Filestore: 99.9% for zonal, 99.95% for regional.
SLA for Databases
Cloud SQL: 99.95% (single zone), 99.99% (HA).
Cloud Spanner: 99.999% for multi-region configurations (e.g., 3 regions). This is the highest SLA on GCP.
Cloud Bigtable: 99.999% for multi-cluster deployments (across zones), 99.9% for single-cluster.
Firestore: 99.95% for the service.
Memorystore: 99.9% for standard tier (with replication), 99.5% for basic tier.
How to Claim SLA Credits
Identify the outage period and affected services.
Calculate the Monthly Uptime Percentage based on Google's published downtime (you can check status.cloud.google.com for historical incidents).
Submit a credit request via the Google Cloud Console under Billing > Credits & Adjustments.
Include required details: project ID, service name, instance IDs, outage timestamps, and any relevant logs.
Google reviews and applies credits within 30 days.
SLA Best Practices
Always design for multi-zone or multi-region to achieve higher SLA tiers.
Use health checks and load balancers to automate failover.
Monitor your own uptime with Cloud Monitoring to detect issues before they affect SLA.
Understand SLA exclusions: scheduled maintenance, customer errors, etc.
For critical workloads, consider using Cloud Spanner with multi-region for 99.999% uptime.
Document your architecture to prove compliance with SLA conditions (e.g., multi-zone deployment).
Determine SLA Eligibility Conditions
Before relying on an SLA, you must ensure your deployment meets the conditions specified in the SLA documentation. For example, for Compute Engine to achieve the 99.99% uptime SLA, you must run instances in at least two zones within a region, use a load balancer with health checks, and configure autohealing. If you run a single instance in one zone, the SLA drops to 99.5%. Similarly, for Cloud SQL HA, you must enable high availability configuration, which provisions a standby instance in another zone with synchronous replication. Check the specific SLA page for each service to understand prerequisites. Failure to meet these conditions means you may not qualify for credits even if the service experiences downtime.
Calculate Monthly Uptime Percentage
Google automatically calculates the Monthly Uptime Percentage (MUP) for each service based on its internal monitoring. However, you can estimate it yourself: MUP = (Total minutes in the month - Downtime minutes) / Total minutes in the month × 100. Downtime is defined as the period during which the service is unavailable as determined by Google's systems. For compute instances, downtime begins when the instance stops responding to health checks and ends when it resumes. For storage, downtime is when requests fail with errors. Google publishes service-specific definitions. The MUP is rounded to two decimal places. For example, a 30-day month has 43,200 minutes. If downtime is 10 minutes, MUP = 99.98%. If downtime is 100 minutes, MUP = 99.77%.
Compare MUP to SLA Thresholds
Each SLA defines thresholds for service credits. For Compute Engine single-zone: if MUP ≥ 99.5%, no credit. If 99.0% ≤ MUP < 99.5%, credit = 10%. If MUP < 99.0%, credit = 25%. For multi-zone: if MUP ≥ 99.99%, no credit. If 99.95% ≤ MUP < 99.99%, credit = 10%. If 95.0% ≤ MUP < 99.95%, credit = 25%. If MUP < 95.0%, credit = 50%. Note that the thresholds are cumulative: the credit percentage applies to the entire monthly bill for the affected service, not just the downtime period. Also, the maximum credit is typically 100% of the monthly fee, but some SLAs cap at 50% for partial outages.
Submit Credit Request Within 30 Days
If you believe the SLA was not met, you must submit a credit request within 30 days after the end of the billing month. The request must include: project ID, service name, instance IDs (if applicable), the outage start and end times in UTC, and a description of the impact. You can submit via the Google Cloud Console under Billing > Credits & Adjustments. Google will review the request against its own monitoring data. If approved, the credit appears as a negative line item on your next invoice. If denied, you can appeal. Note that credits are not automatically applied; you must proactively claim them.
Apply Credits and Verify on Invoice
Once Google approves the credit, it is applied to your account. You can verify by checking the 'Credits' section in the billing report. Credits are typically applied in the following billing cycle. They are calculated as a percentage of the monthly cost of the affected service. For example, if you paid $1,000 for Compute Engine in a month and the SLA credit is 25%, you receive a $250 credit. The credit cannot exceed the total monthly cost for that service. If multiple services are affected, you must submit separate claims. Keep records of your claim and Google's response for auditing.
Enterprise Scenario 1: E-Commerce Platform with Multi-Zone Deployment
A large e-commerce company runs its customer-facing website on Compute Engine instances behind an HTTP(S) Load Balancer. They deploy instances in three zones (us-east1-b, us-east1-c, us-east1-d) to achieve 99.99% SLA. They use managed instance groups with autohealing and health checks. During a regional network event, one zone becomes unreachable for 15 minutes. The load balancer automatically routes traffic to the other zones, so the website remains up. However, the instances in the affected zone are considered down. The MUP for that zone's instances is 99.97% (since they were down 15 min out of 43,200). Since the overall service (the load balancer) is still serving, the SLA for the load balancer is not violated. But the instances in the failed zone individually have an MUP of 99.97%, which is above 99.5% (single-zone) but below 99.99% (multi-zone). However, the SLA for Compute Engine multi-zone requires that the instances are behind a load balancer and the MUP is calculated across all instances? Actually, the SLA applies per instance or per group? The SLA document says: 'For Compute Engine, the SLA applies to each VM instance individually.' So each instance has its own MUP. If an instance in a multi-zone deployment goes down, its MUP drops, and you can claim credit for that instance. The company claimed a 10% credit for the affected instances (since MUP < 99.99% but ≥ 99.95%). They received a small credit. Key lesson: even with multi-zone, individual instance failures can trigger credits, but the overall application remains available.
Enterprise Scenario 2: Financial Services with Cloud Spanner Multi-Region
A financial institution uses Cloud Spanner for its transaction processing. They deploy a multi-region configuration (e.g., us-central1, us-east1, us-west1) to achieve 99.999% SLA. During a major regional outage (e.g., us-central1 goes down), Spanner automatically fails over to the other regions. The failover is transparent to the application, with no data loss. The MUP for the month is 99.999% (downtime of less than 0.44 minutes). No credit is due. However, if a misconfiguration causes a 10-minute outage, the MUP drops to 99.98%, triggering a 10% credit (since below 99.999% but above 99.95%). The institution files a credit request and receives a significant refund. This scenario highlights that even with 99.999% SLA, credits can apply for longer outages. The institution also uses Cloud Monitoring to track latency and error rates, ensuring they meet their own internal SLAs.
Common Misconfiguration: Single-Zone Deployment with No Load Balancer
A startup deploys a single Compute Engine instance in one zone without a load balancer. The instance goes down for 2 hours due to a host failure. The MUP is 99.72% (down 120 min), which is below 99.5%, so they qualify for a 25% credit. However, they did not have a load balancer or multi-zone setup, so they cannot claim the higher SLA tier. They submit a credit request and receive a 25% refund on that instance's cost. But the application was completely down for 2 hours, causing revenue loss. The SLA credit only partially compensates. This shows that relying solely on SLA credits is not a disaster recovery strategy; you must architect for availability.
What the GCDL Exam Tests on SLAs and Uptime Guarantees
The GCDL exam (Objective 2.1: Infrastructure) tests your understanding of GCP SLAs, specifically:
The uptime percentages for major services (Compute Engine, Cloud Storage, BigQuery, Cloud SQL, GKE).
The difference between single-zone and multi-zone SLAs.
The concept of service credits and how they are calculated.
Conditions for SLA eligibility (e.g., using load balancers, multiple zones).
Exclusions (scheduled maintenance, customer actions, beta features).
The fact that SLAs are financial commitments, not availability guarantees.
Common Wrong Answers and Why Candidates Choose Them
1. Wrong: 'Google guarantees 99.99% uptime for all services.' Reality: Each service has a different SLA. Compute Engine single-zone is 99.5%, not 99.99%. Candidates confuse the highest SLA with the default.
2. Wrong: 'If my application is down, I automatically get a credit.' Reality: You must submit a credit request within 30 days. Credits are not automatic. Also, you must meet eligibility conditions (e.g., multi-zone for higher tiers).
3. Wrong: 'SLA credits cover all losses from an outage.' Reality: Credits are capped at 100% of the monthly fee for that service. They do not cover business loss, lost revenue, or indirect damages.
4. Wrong: 'I can get a 100% credit for any outage longer than 5 minutes.' Reality: The credit percentage depends on the MUP. For Compute Engine single-zone, you need MUP < 99.0% to get 25% credit, not 100%. Only extreme outages (MUP < 95% for multi-zone) yield 50% credit.
Specific Numbers and Terms That Appear on the Exam
Compute Engine single-zone: 99.5% uptime.
Compute Engine multi-zone: 99.99% uptime.
Cloud Storage multi-regional: 99.95%.
Cloud Storage regional: 99.9%.
BigQuery: 99.99%.
Cloud SQL single zone: 99.95%; HA: 99.99%.
GKE zonal: 99.5%; regional: 99.95%.
Cloud Spanner multi-region: 99.999%.
Service credit tiers: 10%, 25%, 50% (max).
Claim window: 30 days after month end.
Exclusions: scheduled maintenance (advance notice), beta features, customer actions, force majeure.
Edge Cases the Exam Loves to Test
Single instance in one zone: The SLA is 99.5%, but if you don't use a load balancer, you still get the SLA? Yes, the SLA applies to any VM instance, but the threshold is lower. The exam may ask: 'What is the SLA for a single VM in one zone?' Answer: 99.5%.
Beta features: No SLA. If a question says 'Your app uses a beta API and it goes down,' the correct answer is 'No SLA coverage.'
Scheduled maintenance: If Google notifies you 1 week ahead, downtime is excluded. The exam may present a scenario where maintenance causes 10 minutes of downtime, and ask if credits apply. Answer: No, because it's scheduled.
Multi-zone without load balancer: The higher SLA (99.99%) requires a load balancer. If you have instances in two zones but no load balancer, you get the single-zone SLA? Actually, the SLA for each instance is still 99.5% because the multi-zone SLA requires a load balancer. The exam may test this condition.
How to Eliminate Wrong Answers Using the Underlying Mechanism
If a question mentions 'automatic credits,' eliminate it because credits require a claim.
If a question mentions '100% uptime guarantee,' eliminate it because SLAs are not guarantees.
If a question mentions 'covers all costs,' eliminate it because credits are capped.
If a question mentions 'all services have the same SLA,' eliminate it because they vary.
Focus on the specific numbers: 99.5%, 99.95%, 99.99%, 99.999%.
Remember that higher SLA tiers require multi-zone or multi-region deployments.
Compute Engine single-zone SLA: 99.5% uptime; multi-zone with load balancer: 99.99%.
Cloud Storage multi-regional SLA: 99.95%; regional: 99.9%.
BigQuery SLA: 99.99% uptime.
Cloud SQL HA SLA: 99.99%; single zone: 99.95%.
GKE regional cluster SLA: 99.95%; zonal: 99.5%.
Cloud Spanner multi-region SLA: 99.999% (highest on GCP).
Service credits range from 10% to 50% of monthly bill, capped at 100%.
Credits must be claimed within 30 days after the month ends.
Scheduled maintenance, beta features, and customer actions are excluded from SLA.
SLAs are financial commitments, not technical guarantees; architect for failure.
Multi-zone deployments require a load balancer to qualify for higher SLA tiers.
The GCDL exam expects you to know specific uptime percentages for key services.
These come up on the exam all the time. Here's how to tell them apart.
Single-Zone Deployment
SLA: 99.5% uptime for Compute Engine (approx. 3.6 hours downtime allowed per month).
No load balancer required for SLA eligibility.
Lower architectural complexity and cost.
Risk of complete application outage if zone fails.
Service credit tiers: 10% for MUP < 99.5%, 25% for MUP < 99.0%.
Multi-Zone Deployment
SLA: 99.99% uptime for Compute Engine (approx. 4.4 minutes downtime allowed per month).
Requires load balancer and health checks across at least two zones.
Higher complexity and cost (additional instances, load balancer).
Application remains available if one zone fails.
Service credit tiers: 10% for MUP < 99.99%, 25% for MUP < 99.95%, 50% for MUP < 95.0%.
Mistake
Google guarantees 99.99% uptime for all services.
Correct
Each service has its own SLA. Compute Engine single-zone is 99.5%, not 99.99%. Only services like Cloud Spanner multi-region offer 99.999%.
Mistake
SLA credits are automatically applied when an outage occurs.
Correct
You must submit a credit request within 30 days of the month end. Credits are not automatic.
Mistake
If I use two zones, I automatically get 99.99% uptime SLA for Compute Engine.
Correct
You also need a load balancer distributing traffic across those zones. Without it, each instance still has a single-zone SLA of 99.5%.
Mistake
SLA credits cover all financial losses from an outage.
Correct
Credits are capped at 100% of the monthly fee for the affected service. They do not cover lost revenue, productivity, or other damages.
Mistake
Scheduled maintenance is covered by the SLA and qualifies for credits.
Correct
Scheduled maintenance with advance notice is explicitly excluded from SLA downtime calculations.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The SLA for a single Compute Engine VM instance in one zone is 99.5% monthly uptime. This means Google commits to the instance being available at least 99.5% of the time in a month. If uptime falls below 99.5%, you are eligible for service credits (10% if between 99.0% and 99.5%, 25% if below 99.0%). This SLA applies even if you do not use a load balancer. However, to achieve the higher 99.99% SLA, you must deploy instances in at least two zones behind a load balancer.
To claim a service credit, you must submit a credit request through the Google Cloud Console within 30 days after the end of the billing month in which the outage occurred. Go to Billing > Credits & Adjustments and click 'Submit Credit Request.' You need to provide the project ID, affected service name, instance IDs (if applicable), the start and end times of the outage in UTC, and a description. Google will review your claim against its own monitoring data. If approved, the credit appears as a negative line item on your next invoice.
No, scheduled maintenance is excluded from SLA coverage. Google typically provides at least one week's advance notice for maintenance that may cause downtime. During maintenance, your instances may be live migrated or rebooted. If the migration fails and causes extended unplanned downtime, that portion may be covered. But the scheduled maintenance window itself is not counted as downtime for SLA purposes.
Cloud Spanner offers a 99.999% uptime SLA for multi-region configurations (e.g., three regions). This is the highest SLA of any Google Cloud service. For single-region configurations, the SLA is 99.99%. The 99.999% SLA translates to less than 26 seconds of downtime per month. If the monthly uptime falls below 99.999%, you are eligible for service credits (10% for 99.999% > MUP ≥ 99.95%, 25% for 99.95% > MUP ≥ 99.0%, 50% for MUP < 99.0%).
No, beta features (pre-GA) are not covered by any SLA. Google explicitly states that services or features labeled as 'Beta' are provided without SLA commitments. If you use a beta feature and it experiences downtime, you cannot claim SLA credits. This is a common exam trap: always check if the service is GA before assuming SLA coverage.
Yes, but only in extreme cases. The maximum service credit is 100% of the monthly fee for the affected service. For example, if your Compute Engine instances are down for the entire month (MUP = 0%), you would receive a 100% credit. However, most SLA tiers cap at 50% for partial outages. For multi-zone Compute Engine, the highest credit tier is 50% (for MUP < 95%). So a 100% credit is rare and typically only for total service failure.
You still have an SLA of 99.5% uptime for that instance. If the instance goes down, you can claim credits based on the single-zone thresholds. However, your application will be completely unavailable during the outage. The SLA does not require a load balancer for single-zone deployments, but it also does not provide the higher 99.99% tier. For critical applications, you should always use multi-zone with a load balancer to improve availability and qualify for higher credits.
You've just covered GCP SLAs and Uptime Guarantees — now see how well it sticks with free GCDL practice questions. Full explanations included, no account needed.
Done with this chapter?