--- description: How reliable are Capacitor live updates? Learn what uptime claims of CodePush-style services mean, how to verify them, and how Capawesome Cloud delivers. title: Capacitor Live Updates: Reliability & Uptime - Capawesome image: https://capawesome.io/docs/assets/images/social/blog/capacitor-live-updates-reliability-and-uptime.png --- [Skip to content ](#capacitor-live-updates-reliability-uptime) [📲 Introducing **Build Sharing** — get your builds onto testers' devices with a link & QR code. No account required. ](/blog/share-mobile-app-builds-with-testers/) * [ SDKs ](/docs/sdks/) * [ Formbricks ](/docs/sdks/capacitor/formbricks/) * [ Geocoder ](/docs/sdks/capacitor/geocoder/) * [ Google Sign-In ](/docs/sdks/capacitor/google-sign-in/) * [ Grafana Faro ](/docs/sdks/capacitor/grafana-faro/) * [ Gyroscope ](/docs/sdks/capacitor/gyroscope/) * [ Haptics ](/docs/sdks/capacitor/haptics/) * [ Home Indicator ](/docs/sdks/capacitor/home-indicator/) * [ In-App Browser ](/docs/sdks/capacitor/in-app-browser/) * [ Install Referrer ](/docs/sdks/capacitor/install-referrer/) * [ Intercom ](/docs/sdks/capacitor/intercom/) * [ Intune ](/docs/sdks/capacitor/intune/) * [ Keep Awake ](/docs/sdks/capacitor/keep-awake/) * [ libSQL ](/docs/sdks/capacitor/libsql/) * [ Light Sensor ](/docs/sdks/capacitor/light-sensor/) * [ Live Update ](/docs/sdks/capacitor/live-update/) * [ Localization ](/docs/sdks/capacitor/localization/) * [ Mail Composer ](/docs/sdks/capacitor/mail-composer/) * [ Managed Configurations ](/docs/sdks/capacitor/managed-configurations/) * [ Maps Launcher ](/docs/sdks/capacitor/maps-launcher/) * [ Media Session ](/docs/sdks/capacitor/media-session/) * [ ML Kit ](/docs/sdks/capacitor/mlkit/) * [ Navigation Bar ](/docs/sdks/capacitor/navigation-bar/) * [ Network ](/docs/sdks/capacitor/network/) * [ NFC ](/docs/sdks/capacitor/nfc/) * [ Node.js ](/docs/sdks/capacitor/nodejs/) * [ OAuth ](/docs/sdks/capacitor/oauth/) * [ Passkeys ](/docs/sdks/capacitor/passkeys/) * [ Password Autofill ](/docs/sdks/capacitor/password-autofill/) * [ PDF Generator ](/docs/sdks/capacitor/pdf-generator/) * [ PDF Viewer ](/docs/sdks/capacitor/pdf-viewer/) * [ Pedometer ](/docs/sdks/capacitor/pedometer/) * [ Permissions ](/docs/sdks/capacitor/permissions/) * [ Phone Dialer ](/docs/sdks/capacitor/phone-dialer/) * [ Photo Editor ](/docs/sdks/capacitor/photo-editor/) * [ Photo Manipulator ](/docs/sdks/capacitor/photo-manipulator/) * [ PixLive ](/docs/sdks/capacitor/pixlive/) * [ PostHog ](/docs/sdks/capacitor/posthog/) * [ Printer ](/docs/sdks/capacitor/printer/) * [ Privacy Screen ](/docs/sdks/capacitor/privacy-screen/) * [ Proximity Sensor ](/docs/sdks/capacitor/proximity-sensor/) * [ Purchases ](/docs/sdks/capacitor/purchases/) * [ RealtimeKit ](/docs/sdks/capacitor/realtimekit/) * [ Root Detection ](/docs/sdks/capacitor/root-detection/) * [ Screen Brightness ](/docs/sdks/capacitor/screen-brightness/) * [ Screen Orientation ](/docs/sdks/capacitor/screen-orientation/) * [ Screen Reader ](/docs/sdks/capacitor/screen-reader/) * [ Screenshot ](/docs/sdks/capacitor/screenshot/) * [ Secure Preferences ](/docs/sdks/capacitor/secure-preferences/) * [ Settings Launcher ](/docs/sdks/capacitor/settings-launcher/) * [ Shake ](/docs/sdks/capacitor/shake/) * [ Silent Mode ](/docs/sdks/capacitor/silent-mode/) * [ SIM ](/docs/sdks/capacitor/sim/) * [ SMS Composer ](/docs/sdks/capacitor/sms-composer/) * [ Speech Recognition ](/docs/sdks/capacitor/speech-recognition/) * [ Speech Synthesis ](/docs/sdks/capacitor/speech-synthesis/) * [ Share Target ](/docs/sdks/capacitor/share-target/) * [ Square Mobile Payments ](/docs/sdks/capacitor/square-mobile-payments/) * [ SQLite ](/docs/sdks/capacitor/sqlite/) * [ Superwall ](/docs/sdks/capacitor/superwall/) * [ System WebView ](/docs/sdks/capacitor/system-webview/) * [ Tauri ](/docs/sdks/capacitor/tauri/) * [ Text Interaction ](/docs/sdks/capacitor/text-interaction/) * [ Text Zoom ](/docs/sdks/capacitor/text-zoom/) * [ Thermal State ](/docs/sdks/capacitor/thermal-state/) * [ Toast ](/docs/sdks/capacitor/toast/) * [ Torch ](/docs/sdks/capacitor/torch/) * [ Vault ](/docs/sdks/capacitor/vault/) * [ Volume ](/docs/sdks/capacitor/volume/) * [ Wallet ](/docs/sdks/capacitor/wallet/) * [ Wifi ](/docs/sdks/capacitor/wifi/) * [ YouTube Player ](/docs/sdks/capacitor/youtube-player/) * [ Zip ](/docs/sdks/capacitor/zip/) * [ Cordova ](/docs/sdks/cordova/) * [ Cloud ](/docs/cloud/) * [ Integrations ](/docs/cloud/live-updates/integrations/) * Concepts * Reference * [ Troubleshooting ](/docs/cloud/live-updates/troubleshooting/) * [ FAQ ](/docs/cloud/live-updates/faq/) * [ Native Builds ](/docs/cloud/native-builds/) * [ Set Up Environments ](/docs/cloud/native-builds/environments/) * [ Set Up Native Configurations ](/docs/cloud/native-builds/native-configurations/) * [ Auto-Increment Build Numbers ](/docs/cloud/native-builds/auto-incrementing-build-numbers/) * [ Configure the Web Build Script ](/docs/cloud/native-builds/web-build-script/) * [ Build from a Monorepo ](/docs/cloud/native-builds/monorepo/) * [ Use pnpm, Yarn, or bun ](/docs/cloud/native-builds/package-managers/) * [ Install Private npm Packages ](/docs/cloud/native-builds/npm-private-registry/) * [ Override the Java Version ](/docs/cloud/native-builds/override-java-version/) * [ Custom iOS Provisioning Profiles ](/docs/cloud/native-builds/custom-ios-provisioning-profiles/) * [ Build without Git ](/docs/cloud/native-builds/build-without-git/) * [ Access Git Behind a Firewall ](/docs/cloud/native-builds/firewall-access/) * [ Integrations ](/docs/cloud/native-builds/integrations/) * Reference * [ Troubleshooting ](/docs/cloud/native-builds/troubleshooting/) * [ FAQ ](/docs/cloud/native-builds/faq/) * [ App Store Publishing ](/docs/cloud/app-store-publishing/) * [ Submit a Build ](/docs/cloud/app-store-publishing/submit-a-build/) * [ Submit Automatically After a Build ](/docs/cloud/app-store-publishing/submit-automatically/) * [ Troubleshooting ](/docs/cloud/app-store-publishing/troubleshooting/) * [ FAQ ](/docs/cloud/app-store-publishing/faq/) * [ Automations ](/docs/cloud/automations/) * [ Reference ](/docs/cloud/automations/reference/) * [ Troubleshooting ](/docs/cloud/automations/troubleshooting/) * [ FAQ ](/docs/cloud/automations/faq/) * [ Assist ](/docs/cloud/assist/) * [ CLI ](/docs/cloud/cli/) * APIs and SDKs * [ Webhooks ](/docs/cloud/webhooks/) * [ Integrations ](/docs/cloud/integrations/) * Notifications * Account * [ Organization ](/docs/cloud/organizations/) * [ Two-Factor Enforcement ](/docs/cloud/organizations/two-factor-authentication/) * [ Network Restrictions ](/docs/cloud/organizations/network-restrictions/) * [ Audit Logs ](/docs/cloud/organizations/audit-logs/) * [ Billing ](/docs/cloud/organizations/billing/) * [ License Keys ](/docs/cloud/license-keys/) * [ AI ](/docs/ai/) * [ Insiders ](/docs/insiders/) * [ Billing & Plans ](/docs/insiders/billing-and-plans/) * [ FAQ ](/docs/insiders/faq/) * [ License ](https://capawesome.io/legal/eula/) * [ Support ](/docs/support/) * [ Contributing ](/docs/contributing/) * Contributing code * [ Code of Conduct ](/docs/contributing/code-of-conduct/) * [ Questions ](https://docs.github.com/en/discussions/collaborating-with-your-community-using-discussions/participating-in-a-discussion#creating-a-discussion) * [ Blog ](/blog/) * Categories * [ FAQ ](#faq) * [ Try Capawesome Cloud ](#try-capawesome-cloud) * [ Conclusion ](#conclusion) * Related links # Capacitor Live Updates: Reliability & Uptime[¶](#capacitor-live-updates-reliability-uptime "Permanent link") Live updates are the tool you reach for when something is already broken in production. That makes the reliability and uptime of your Capacitor live update service critical: a delivery pipeline that fails during an incident defeats its own purpose. In this guide, we break down what the uptime claims of live update and CodePush services really mean, how to verify them yourself in about ten minutes, and how Capawesome Cloud is engineered to meet exactly this standard. [ ![Build and deploy your Capacitor app with Capawesome Cloud](https://capawesome.io/assets/banners/cloud-build-and-deploy-capacitor-apps.png?t=1) ](https://capawesome.io/) ## Key Takeaways[¶](#key-takeaways "Permanent link") * A 99.9% uptime commitment allows 43 minutes and 50 seconds of downtime per month; 99.5% allows 3 hours and 39 minutes. * Only a contractual SLA turns an uptime number into a commitment, by defining how uptime is measured, what is excluded, and which service credits apply. * You can verify any provider's uptime claims in minutes: look for a probe-based public status page, an incident history of at least 90 days, and an SLA that covers your plan. * A perfect uptime record only counts if it comes from automated monitoring; an always-green, manually curated status page proves nothing. * With a well-designed live update SDK, a server outage never breaks installed apps: they keep running the active bundle, and automatic rollbacks protect against broken updates. * Capawesome Cloud runs on Cloudflare, PlanetScale, and Sentry, is SOC 2 Type II audited, publishes a public status page with 60-second checks, and backs uptime with a contractual SLA. ## Why Does Reliability Matter for Live Updates?[¶](#why-does-reliability-matter-for-live-updates "Permanent link") A live update service delivers new versions of your app's web assets directly to installed apps, skipping the app store review process. That speed is the whole point: teams use live updates to ship hotfixes in minutes instead of days. It also means the service becomes part of your critical infrastructure. The moment you need it most is usually the moment something is already broken, and an update service that is down during your incident turns one problem into two. Reliability in this market has a second dimension: whether the service will still exist next year. Microsoft retired App Center, including the hosted CodePush service, on [March 31, 2025](https://learn.microsoft.com/en-us/appcenter/retirement) and archived the open source CodePush repositories two months later. Ionic stopped selling Appflow to new customers in [February 2025](https://ionic.io/blog/important-announcement-the-future-of-ionics-commercial-products) and will sunset the service on December 31, 2027\. The two best-known products in this space ended within a few years of each other, forcing thousands of teams to find a [CodePush alternative](/blog/migrating-from-app-center-to-capawesome-cloud/) or an [Appflow alternative](/blog/alternative-to-appflow/). So when you evaluate a provider, you are evaluating both its infrastructure and its staying power. We have written about the latter in [Built to Last: The Capawesome Story](/blog/built-to-last-the-capawesome-story/); this post focuses on the technical side. ## What Does 99.9% Uptime Actually Mean?[¶](#what-does-999-uptime-actually-mean "Permanent link") An uptime of 99.9% allows 43 minutes and 50 seconds of downtime per month. Whether that is acceptable depends on your app, but you should know what the number means before you compare providers. Here is what the common commitments translate to, based on an average month of 30.44 days: | Uptime | Downtime per month | Downtime per year | | ------ | ------------------ | ----------------- | | 99% | 7 h 18 min | 3 d 15 h 40 min | | 99.5% | 3 h 39 min | 1 d 19 h 50 min | | 99.9% | 43 min 50 s | 8 h 46 min | | 99.95% | 21 min 55 s | 4 h 23 min | | 99.99% | 4 min 23 s | 52 min 36 s | Two things are worth knowing about these numbers. First, availability multiplies: a request that passes through four components with 99.99% availability each ends up at 99.96% overall. That is why honest end-to-end numbers are rarely a long string of nines. Second, a percentage only has meaning together with a measurement method. A service level agreement (SLA) specifies how uptime is measured, which downtime is excluded (such as scheduled maintenance), and what compensation you receive if the target is missed. A number on a homepage without an SLA behind it is a goal, not a commitment. ## How Do You Verify a Provider's Uptime Claims?[¶](#how-do-you-verify-a-providers-uptime-claims "Permanent link") You can verify uptime claims with three artifacts: a public status page fed by real monitoring data, an incident history, and a contractual SLA. If none of the three exist, the claim cannot be verified. In this market, it is common to find uptime percentages on homepages that appear in neither an SLA document nor a status page history. That does not necessarily mean bad faith, but it does mean the number is unverifiable, and you should not base a production decision on it. Here is a checklist you can run against any provider, including us: 1. **Find the status page.** Check the website footer or try `status.`. If there is no status page, there is nothing to verify, and that is your answer. 2. **Check how far the history goes back.** A 30-day window can hide a bad quarter. Look for at least 90 days of data and an incident archive with dates. 3. **Ask where the number comes from.** Some status pages compute uptime from component statuses that are set manually, which only measures whether someone flipped a switch. Prefer pages fed by automated probes from an external monitoring service. 4. **Be skeptical of a spotless record you can't audit.** On a probe-based status page, downtime shows up automatically, so a clean stretch is credible evidence. On a manually curated page, years of green only mean that nobody posted anything. If a provider shows 100% across all components for years with no measurement trail, assume nothing is being measured. 5. **Read the SLA, not the homepage.** An SLA defines how uptime is measured, which situations are excluded, what service credits you receive, and how to claim them. Also check whether the SLA applies to your plan at all; some providers reserve it for enterprise tiers. 6. **Measure it yourself.** Point a free external monitor at the provider's public endpoints for 60 to 90 days and compare the results with their published numbers. A provider that takes reliability seriously will hold up to this scrutiny, and most will welcome it. ## What Happens When an Update Service Goes Down?[¶](#what-happens-when-an-update-service-goes-down "Permanent link") With a well-designed live update SDK, a server outage is a non-event for your users. The active bundle is stored on the device, so installed apps keep running exactly as before. A failed update check is simply ignored: no update is applied, and the app carries on. Users are never blocked at launch because the update service is unreachable; only the delivery of new updates is delayed until the service recovers. This is exactly [how live updates work](/docs/cloud/live-updates/how-it-works/) with Capawesome Cloud. In day-to-day operation, the bigger risk is a broken update rather than a down server. That is why rollback capabilities matter at least as much as uptime. With [automatic rollbacks](/docs/cloud/live-updates/rollbacks/), the Live Update SDK reverts to the bundle that shipped with the installed native app if a new bundle fails to signal `ready()` in time, and that bundle is guaranteed to run on the current binary. Bundles that triggered a rollback can be blocked from being applied again, which prevents rollback loops. [Gradual rollouts](/docs/cloud/live-updates/rollouts/) limit how many users a bad update can reach in the first place, and a manual rollback is one CLI command or one click in the Cloud Console. So when you compare providers, ask two questions: what is your uptime, and what happens to my users when it isn't 100%? ## How Is Capawesome Cloud Engineered for Reliability?[¶](#how-is-capawesome-cloud-engineered-for-reliability "Permanent link") Capawesome Cloud approaches reliability the same way we just asked you to evaluate it: proven infrastructure, disciplined change management, continuous monitoring, tested rollback paths, and claims you can check yourself. ### Proven Infrastructure Providers[¶](#proven-infrastructure-providers "Permanent link") We deliberately build on infrastructure providers with a track record at massive scale. Live update bundles and API traffic are served through [Cloudflare](https://www.cloudflare.com/network/), whose network spans 337 cities and reaches about 95% of the world's internet-connected population within 50 milliseconds. Your users download updates from an edge location near them instead of a single origin server. Metadata such as bundle and device records is stored in [PlanetScale](https://planetscale.com/postgres) Postgres, which runs every database as a primary plus two replicas across three availability zones by default, with automated failover that typically completes in under 30 seconds. Errors across the platform are tracked in [Sentry](https://sentry.io/), so regressions surface in real time instead of waiting for support tickets. The full [list of subprocessors](https://capawesome.io/legal/subprocessors/) is public. The Live Update API is available on separate US and EU endpoints, and with the [EU endpoint](/docs/cloud/live-updates/privacy/), not even IP addresses leave the European Union. If your security requirements demand it, you can even [self-host your bundles](/docs/cloud/live-updates/self-hosting/) and use Capawesome Cloud only for update metadata. ### How We Manage Change[¶](#how-we-manage-change "Permanent link") Most outages are caused by change, not by failing hardware; Google's Site Reliability Engineering book attributes [roughly 70% of outages](https://sre.google/sre-book/introduction/) to changes in a live system. Every change to Capawesome Cloud goes through code review and automated tests before it is deployed, and every deployment has a rollback plan. Larger changes are rolled out gradually, so problems surface with limited impact and can be reverted before they reach everyone. The same discipline applies to our suppliers: we notify customers at least 30 days before engaging a new or changed subprocessor. ### Monitoring, Alerting, and Incident Response[¶](#monitoring-alerting-and-incident-response "Permanent link") We don't wait for users to tell us something is down. An independent monitoring service probes our public endpoints every 60 seconds, and the results feed our public status page. Application errors alert the team in real time through Sentry. When something does go wrong, we follow a documented [incident response process](https://capawesome.io/legal/security-policy/) covering detection, containment, remediation, and post-incident review, and we notify affected customers of personal data breaches within 48 hours. These practices are audited every year as part of our [SOC 2 Type II certification](/blog/capawesome-cloud-soc-2-type-2-compliance/), which includes the availability trust criterion. ### Security That Protects Update Integrity[¶](#security-that-protects-update-integrity "Permanent link") A tampered update is worse than downtime. All traffic is encrypted in transit, and data is encrypted at rest. With end-to-end [code signing](/docs/cloud/live-updates/code-signing/), you sign every bundle with your private key, and the [Live Update SDK](/docs/cloud/live-updates/setup/) verifies the signature on the device before applying the update. Unsigned or modified bundles are rejected. [Protected channels](/docs/cloud/live-updates/channels/#protected-channels) go one step further and refuse to distribute any bundle that is not code-signed. And because the SDK is open source, you can verify exactly what data leaves your users' devices. For a full breakdown of what each of these controls protects, and where bundle encryption fits in, read [Capacitor Live Updates: Signing vs Encryption](/blog/capacitor-live-updates-end-to-end-encryption/). ### Verify Our Claims Yourself[¶](#verify-our-claims-yourself "Permanent link") Everything above is checkable with the checklist from this post. Our [status page](https://status.capawesome.io) is public and fed by an external monitor that checks our endpoints every 60 seconds. As of August 9, 2026, it shows 100.000% uptime over the trailing 90 days for the website, the Cloud Console, and the NPM registry, and 99.986% (EU) and 99.987% (US) for the API endpoints. We publish these numbers instead of a flat 100% because this is what real infrastructure looks like, and you can check the current values live at any time. Our [Service Level Agreement](https://capawesome.io/legal/service-level-agreement/) is public as well: 99.5% per calendar month on paid plans and 99.9% with the Enterprise SLA add-on, including a defined measurement method, exclusions, and service credits. And if you want independent evidence, point your own monitor at our endpoints. We mean it. ## FAQ[¶](#faq "Permanent link") ### What happened to CodePush?[¶](#what-happened-to-codepush "Permanent link") Microsoft retired the hosted CodePush service together with Visual Studio App Center on March 31, 2025, and archived the open source CodePush repositories in May 2025 without naming a successor. Teams that relied on it had to switch to another live update provider. If you are one of them, our guide on [migrating from App Center to Capawesome Cloud](/blog/migrating-from-app-center-to-capawesome-cloud/) walks you through the transition. ### How much downtime does 99.9% uptime allow?[¶](#how-much-downtime-does-999-uptime-allow "Permanent link") An uptime of 99.9% allows 43 minutes and 50 seconds of downtime per month, or 8 hours and 46 minutes per year, based on an average month of 30.44 days. For comparison, 99.5% allows 3 hours and 39 minutes per month, and 99.99% allows 4 minutes and 23 seconds. ### Is a status page with zero incidents a good sign?[¶](#is-a-status-page-with-zero-incidents-a-good-sign "Permanent link") It depends on where the data comes from. If the page is fed by automated probes, downtime would appear automatically, and a clean record is meaningful. If the page is updated manually, an empty incident history only shows that nothing was posted. Check for automated monitoring data and a history of at least 90 days before trusting a perfect record. ### Do live updates keep working when the update server is down?[¶](#do-live-updates-keep-working-when-the-update-server-is-down "Permanent link") Installed apps are not affected by an update server outage. The Live Update SDK stores the active bundle on the device, so apps keep running normally, and a failed update check is simply ignored. Only the delivery of new updates is delayed until the service is available again. ### What is the difference between an SLA and an uptime claim?[¶](#what-is-the-difference-between-an-sla-and-an-uptime-claim "Permanent link") An SLA is a contract: it defines how uptime is measured, which downtime is excluded, and what service credits you receive if the target is missed. An uptime claim without an SLA behind it is a marketing statement. Before relying on a provider's number, check that an SLA document exists and that it applies to your plan. ## Try Capawesome Cloud[¶](#try-capawesome-cloud "Permanent link") The best way to evaluate a live update service is to test it. Create a free Capawesome Cloud account, publish your first live update in minutes, and verify everything in this post yourself, from the status page to automatic rollbacks and code signing. [Try Capawesome Cloud Free](https://capawesome.io) ## Conclusion[¶](#conclusion "Permanent link") Reliability claims are easy to publish and hard to fake once you know where to look. A probe-based status page, a real incident history, a contractual SLA, and an SDK that keeps apps running when the network doesn't: these signals separate dependable live update services from hopeful marketing, and they take about ten minutes to check. Capawesome Cloud is built to pass exactly this test, and we would rather you run the checklist than take our word for it. If you want to go deeper, our [complete guide to Capacitor live updates](/blog/capacitor-live-updates-guide/) covers setup, update strategies, and best practices end to end. For questions and feedback, join the [Capawesome Discord server](https://discord.gg/VCXxSVjefW), and subscribe to the [Capawesome newsletter](https://capawesome.io/newsletter/) to stay up to date on the latest news. August 9, 2026 Back to top ```json { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "Capacitor Live Updates: Reliability \u0026 Uptime", "description": "How reliable are Capacitor live updates? Learn what uptime claims of CodePush-style services mean, how to verify them, and how Capawesome Cloud delivers.", "image": "https://capawesome.io/assets/banners/cloud-build-and-deploy-capacitor-apps.png", "datePublished": "2026-08-10T00:00:00+00:00", "dateModified": "2026-08-10T00:00:00+00:00", "author": [ { "@type": "Person", "name": "Robin Genz", "url": "https://github.com/robingenz" } ], "publisher": { "@type": "Organization", "name": "Capawesome", "url": "https://capawesome.io", "logo": { "@type": "ImageObject", "url": "https://capawesome.io/assets/images/logo.svg" } }, "articleSection": "Capacitor", "keywords": ["Capacitor", "Cloud", "Guides"], "isPartOf": { "@type": "Blog", "@id": "https://capawesome.io/blog/#blog" }, "mainEntityOfPage": "https://capawesome.io/blog/capacitor-live-updates-reliability-and-uptime/", "url": "https://capawesome.io/blog/capacitor-live-updates-reliability-and-uptime/" } { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://capawesome.io/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://capawesome.io/blog/" }, { "@type": "ListItem", "position": 3, "name": "Capacitor Live Updates: Reliability \u0026 Uptime", "item": "https://capawesome.io/blog/capacitor-live-updates-reliability-and-uptime/" } ] } {"@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [{"@type": "Question", "name": "Why Does Reliability Matter for Live Updates?", "acceptedAnswer": {"@type": "Answer", "text": "A live update service delivers new versions of your app's web assets directly to installed apps, skipping the app store review process. That speed is the whole point: teams use live updates to ship hotfixes in minutes instead of days. It also means the service becomes part of your critical infrastructure. The moment you need it most is usually the moment something is already broken, and an update service that is down during your incident turns one problem into two. Reliability in this market has a second dimension: whether the service will still exist next year. Microsoft retired App Center, including the hosted CodePush service, on March 31, 2025 and archived the open source CodePush repositories two months later. Ionic stopped selling Appflow to new customers in February 2025 and will sunset the service on December 31, 2027. The two best-known products in this space ended within a few years of each other, forcing thousands of teams to find a CodePush alternative or an Appflow alternative. So when you evaluate a provider, you are evaluating both its infrastructure and its staying power. We have written about the latter in Built to Last: The Capawesome Story; this post focuses on the technical side."}}, {"@type": "Question", "name": "What Does 99.9% Uptime Actually Mean?", "acceptedAnswer": {"@type": "Answer", "text": "An uptime of 99.9% allows 43 minutes and 50 seconds of downtime per month. Whether that is acceptable depends on your app, but you should know what the number means before you compare providers. Here is what the common commitments translate to, based on an average month of 30.44 days: Uptime Downtime per month Downtime per year 99% 7 h 18 min 3 d 15 h 40 min 99.5% 3 h 39 min 1 d 19 h 50 min 99.9% 43 min 50 s 8 h 46 min 99.95% 21 min 55 s 4 h 23 min 99.99% 4 min 23 s 52 min 36 s Two things are worth knowing about these numbers. First, availability multiplies: a request that passes through four components with 99.99% availability each ends up at 99.96% overall. That is why honest end-to-end numbers are rarely a long string of nines. Second, a percentage only has meaning together with a measurement method. A service level agreement (SLA) specifies how uptime is measured, which downtime is excluded (such as scheduled maintenance), and what compensation you receive if the target is missed. A number on a homepage without an SLA behind it is a goal, not a commitment."}}, {"@type": "Question", "name": "How Do You Verify a Provider's Uptime Claims?", "acceptedAnswer": {"@type": "Answer", "text": "You can verify uptime claims with three artifacts: a public status page fed by real monitoring data, an incident history, and a contractual SLA. If none of the three exist, the claim cannot be verified. In this market, it is common to find uptime percentages on homepages that appear in neither an SLA document nor a status page history. That does not necessarily mean bad faith, but it does mean the number is unverifiable, and you should not base a production decision on it. Here is a checklist you can run against any provider, including us: Find the status page. Check the website footer or try status.. If there is no status page, there is nothing to verify, and that is your answer. Check how far the history goes back. A 30-day window can hide a bad quarter. Look for at least 90 days of data and an incident archive with dates. Ask where the number comes from. Some status pages compute uptime from component statuses that are set manually, which only measures whether someone flipped a switch. Prefer pages fed by automated probes from an external monitoring service. Be skeptical of a spotless record you can't audit. On a probe-based status page, downtime shows up automatically, so a clean stretch is credible evidence. On a manually curated page, years of green only mean that nobody posted anything. If a provider shows 100% across all components for years with no measurement trail, assume nothing is being measured. Read the SLA, not the homepage. An SLA defines how uptime is measured, which situations are excluded, what service credits you receive, and how to claim them. Also check whether the SLA applies to your plan at all; some providers reserve it for enterprise tiers. Measure it yourself. Point a free external monitor at the provider's public endpoints for 60 to 90 days and compare the results with their published numbers. A provider that takes reliability seriously will hold up to this scrutiny, and most will welcome it."}}, {"@type": "Question", "name": "What Happens When an Update Service Goes Down?", "acceptedAnswer": {"@type": "Answer", "text": "With a well-designed live update SDK, a server outage is a non-event for your users. The active bundle is stored on the device, so installed apps keep running exactly as before. A failed update check is simply ignored: no update is applied, and the app carries on. Users are never blocked at launch because the update service is unreachable; only the delivery of new updates is delayed until the service recovers. This is exactly how live updates work with Capawesome Cloud. In day-to-day operation, the bigger risk is a broken update rather than a down server. That is why rollback capabilities matter at least as much as uptime. With automatic rollbacks, the Live Update SDK reverts to the bundle that shipped with the installed native app if a new bundle fails to signal ready() in time, and that bundle is guaranteed to run on the current binary. Bundles that triggered a rollback can be blocked from being applied again, which prevents rollback loops. Gradual rollouts limit how many users a bad update can reach in the first place, and a manual rollback is one CLI command or one click in the Cloud Console. So when you compare providers, ask two questions: what is your uptime, and what happens to my users when it isn't 100%?"}}, {"@type": "Question", "name": "How Is Capawesome Cloud Engineered for Reliability?", "acceptedAnswer": {"@type": "Answer", "text": "Capawesome Cloud approaches reliability the same way we just asked you to evaluate it: proven infrastructure, disciplined change management, continuous monitoring, tested rollback paths, and claims you can check yourself."}}, {"@type": "Question", "name": "What happened to CodePush?", "acceptedAnswer": {"@type": "Answer", "text": "Microsoft retired the hosted CodePush service together with Visual Studio App Center on March 31, 2025, and archived the open source CodePush repositories in May 2025 without naming a successor. Teams that relied on it had to switch to another live update provider. If you are one of them, our guide on migrating from App Center to Capawesome Cloud walks you through the transition."}}, {"@type": "Question", "name": "How much downtime does 99.9% uptime allow?", "acceptedAnswer": {"@type": "Answer", "text": "An uptime of 99.9% allows 43 minutes and 50 seconds of downtime per month, or 8 hours and 46 minutes per year, based on an average month of 30.44 days. For comparison, 99.5% allows 3 hours and 39 minutes per month, and 99.99% allows 4 minutes and 23 seconds."}}, {"@type": "Question", "name": "Is a status page with zero incidents a good sign?", "acceptedAnswer": {"@type": "Answer", "text": "It depends on where the data comes from. If the page is fed by automated probes, downtime would appear automatically, and a clean record is meaningful. If the page is updated manually, an empty incident history only shows that nothing was posted. Check for automated monitoring data and a history of at least 90 days before trusting a perfect record."}}, {"@type": "Question", "name": "Do live updates keep working when the update server is down?", "acceptedAnswer": {"@type": "Answer", "text": "Installed apps are not affected by an update server outage. The Live Update SDK stores the active bundle on the device, so apps keep running normally, and a failed update check is simply ignored. Only the delivery of new updates is delayed until the service is available again."}}, {"@type": "Question", "name": "What is the difference between an SLA and an uptime claim?", "acceptedAnswer": {"@type": "Answer", "text": "An SLA is a contract: it defines how uptime is measured, which downtime is excluded, and what service credits you receive if the target is missed. An uptime claim without an SLA behind it is a marketing statement. Before relying on a provider's number, check that an SLA document exists and that it applies to your plan."}}], "url": "https://capawesome.io/blog/capacitor-live-updates-reliability-and-uptime/"} ```