Skip to main content
Lokalise logo

Is Lokalise Down?

No — Lokalise is up

Reachable from all 8 checked regions

Average response time: 749ms

Last checked · checks run every 6 hours

Official status page: https://status.lokalise.com

Lokalise uptime

100%
Last 7 days
100%
Last 30 days
100%
Last 90 days
781ms
Avg response, 30 days

Measured from multiple regions every 6 hours. Percentages count only checks that returned an availability answer — 11 days measured so far. A dash means that window does not yet hold enough measured days to publish a figure.

30-day history

11-day clean streak
Aug 22: no data
Aug 23: no data
Aug 24: no data
Aug 25: no data
Aug 26: no data
Aug 27: no data
Aug 28: no data
Aug 29: no data
Aug 30: no data
Aug 31: no data
Sep 1: no data
Sep 2: no data
Sep 3: no data
Sep 4: no data
Sep 5: no data
Sep 6: no data
Sep 7: no data
Sep 8: no data
Sep 9: no data
Sep 10: 100.00% uptime, 16 checks
Sep 11: 100.00% uptime, 32 checks
Sep 12: 100.00% uptime, 31 checks
Sep 13: 100.00% uptime, 31 checks
Sep 14: 100.00% uptime, 32 checks
Sep 15: 100.00% uptime, 56 checks
Sep 16: 100.00% uptime, 31 checks
Sep 17: 100.00% uptime, 39 checks
Sep 18: 100.00% uptime, 32 checks
Sep 19: 100.00% uptime, 32 checks
Sep 20: 100.00% uptime, 24 checks
Aug 22 Today
No downtime Partial Downtime Not measurable No data

Reachability by region

Each region runs its own request from a different part of the world. A service can be up for one continent and down for another, which is usually the first sign of a routing or CDN problem.

ams
105ms
DNS 27ms TCP 2ms TLS 4ms TTFB 88ms
arn
208ms
DNS 99ms TCP 1ms TLS 3ms TTFB 195ms
bom
2065ms
DNS 29ms TCP 119ms TLS 608ms TTFB 1142ms
cdg
154ms
DNS 76ms TCP 1ms TLS 6ms TTFB 135ms
dfw
520ms
DNS 66ms TCP 1ms TLS 4ms TTFB 492ms
sjc
517ms
DNS 20ms TCP 1ms TLS 3ms TTFB 505ms
syd
1908ms
DNS 174ms TCP 147ms TLS 149ms TTFB 1052ms
yyz
516ms
DNS 117ms TCP 8ms TLS 12ms TTFB 470ms

What Lokalise does

Lokalise is a localization platform where product teams manage translated strings for apps, websites and documentation. Developers sync keys from their repositories, translators work in the web editor, and the finished strings are pulled back into a build or pushed to released mobile apps over the air, so the platform sits between the engineering workflow and the words users read.

What an outage looks like

The web editor fails to load or translators cannot save their work, so a translation round stalls without anything visibly breaking in the product. Builds and pipelines that pull strings through the API fail at the download step. Over-the-air translation updates stop reaching released mobile apps, which keep running on whatever they last received rather than showing an error.

What to do about it

Read status.lokalise.com, which reports Lokalise.com, Lokalise API, Lokalise App, Lokalise OTA and Lokalise Messages as separate components. Match the symptom to the row. If only OTA is affected, your team's work in the editor continues normally and the impact sits in shipped apps instead. Avoid re-running a failed string sync repeatedly during an incident, and do not merge a partial download into a release branch.

Is it down for everyone, or just you?

If this page says Lokalise is up but it is not loading for you, the problem is between you and them. Run a check against any URL from up to 18 cities across three regions to find out where it breaks.

Test it yourself

Related services

GitHub
GitHub
GitLab
GitLab
AWS
AWS
Cloudflare
Cloudflare

Lokalise outage FAQ

Will my released mobile app break if Lokalise OTA is down?
No, and the fallback is the useful part to know. Lokalise mobile SDKs fall back to the last translations successfully fetched and stored on the device, or to the translations bundled into the app at build time. So an OTA incident freezes copy at its last known version rather than producing missing strings. Users of an already-running app are unlikely to notice anything at all.
Why is a fresh install showing older wording than my own phone?
Because the two devices have different fallbacks. A device that has used the app before holds the last translations it fetched, while a fresh install has only what shipped inside the bundle. During an OTA incident neither can update, so a new install can show wording from the release build while an existing install shows something newer. Both recover on the next successful fetch.
My build failed pulling strings from Lokalise. What should I do?
Stop the pipeline rather than shipping what it managed to download. A partial or failed download during an incident can produce a string file missing keys, and merging that into a release replaces working translations with gaps that reach users. Check the Lokalise API row on status.lokalise.com, keep the last known good string files, and re-run the sync once the component recovers.
Will translation work saved during an outage be lost?
Work that the editor confirmed as saved before an incident is stored. The risk is in-flight edits: text typed while the connection was failing may never have reached Lokalise, even where the interface still appeared to accept it. Lokalise does not publish behaviour for every failure mode, so translators should copy anything substantial elsewhere before refreshing, since refreshing is what discards unsaved local state.
Is it Lokalise or my API token?
Compare scope and the error. An expired or revoked token, a project permission change or a hit rate limit affects one integration and usually returns a specific authorisation or quota message. A Lokalise incident affects every project at once and shows on the status page. Check the status page before you rotate a token, because rotating during an incident leaves you unsure which change fixed it.

How we measure this

  • We request Lokalise's public endpoint every 6 hours from Fly.io regions across six continents — the most recent check ran from 8 of them.
  • A region counts as down only when it gets no usable HTTP response. A 403 or 429 means the origin answered and refused us, which we report as blocked, never as an outage.
  • A single failing region is treated as probe noise. We only change the verdict when two consecutive cycles agree.
  • Response times average only the regions that actually served the page, so a timeout never inflates the number.
  • Where Lokalise publishes an official status feed we read it too. An all-clear from the vendor can soften an unconfirmed degradation; a vendor-declared outage only worsens our verdict when our own checks corroborate it.

Get alerted when Lokalise goes down

This page refreshes every 6 hours. Your own monitors run as often as every 30 seconds, from up to 18 cities across three regions, and tell you the moment something breaks.

Start Free Monitoring
Free plan available No credit card required