Is GitBook Down?

No — GitBook is up

Reachable from all 8 checked regions

Average response time: 120ms

Last checked 5 hours ago · checks run every 6 hours

Official status page: https://www.gitbookstatus.com

GitBook uptime

100%

Last 7 days

100%

Last 30 days

100%

Last 90 days

107ms

Avg response, 30 days

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

30-day history

21-day clean streak

Aug 12 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.

cdg

67ms

DNS 0ms TCP 2ms TLS 7ms TTFB 44ms

dfw

188ms

DNS 0ms TCP 2ms TLS 15ms TTFB 139ms

ewr

104ms

DNS 2ms TCP 2ms TLS 8ms TTFB 74ms

fra

64ms

DNS 0ms TCP 1ms TLS 10ms TTFB 43ms

gru

78ms

DNS 0ms TCP 2ms TLS 9ms TTFB 42ms

iad

70ms

DNS 0ms TCP 1ms TLS 7ms TTFB 44ms

jnb

213ms

DNS 0ms TCP 0ms TLS 8ms TTFB 181ms

lax

179ms

DNS 0ms TCP 1ms TLS 19ms TTFB 144ms

What GitBook does

GitBook is a documentation platform where teams write, publish and maintain product docs and internal knowledge bases. It supports a docs-as-code workflow with Git sync alongside a web editor, and it publishes public sites for customer-facing documentation. Engineering and support teams depend on it, so an outage takes down the pages customers reach for when something else is already broken.

What an outage looks like

Published documentation sites return errors or fail to load for readers, which is the most visible symptom because those pages are public. The editor will not open spaces, or edits fail to save. Git sync stops mirroring changes between GitBook and the repository, so the two drift apart. Search inside a published site stops returning results while the pages themselves still render.

What to do about it

gitbookstatus.com tracks the GitBook App, Public Content and the Homepage as separate components, which distinguishes an authoring outage from one your readers can see. Public Content is the row that matters when customers report broken docs. If Git sync is affected, avoid forcing a re-sync during the incident, because conflicting writes are harder to unpick afterwards than a delay is.

Is it down for everyone, or just you?

If this page says GitBook 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

GitBook outage FAQ

My docs site is down but I can still edit. Which one is broken?

That split is expected, because GitBook tracks the App and Public Content as separate components. The editor working while published pages fail means authoring is healthy and delivery is not. Readers see the outage and you do not, so check the Public Content row rather than judging from the editor in front of you.

Will I lose edits made during an outage?

Edits that saved successfully are kept; the risk is work typed while the editor could not reach GitBook. Before closing the tab, copy anything substantial you wrote during the incident into a local file. Once the App component recovers, reopen the space and confirm your changes are present rather than assuming an autosave caught them.

Does a GitBook outage affect Git sync?

It can. Git sync moves content between GitBook and your repository, so an App outage can leave the two out of step until it clears. The usual outcome is a delay rather than lost content. Let it reconcile on its own once the incident ends instead of forcing a sync, which risks conflicting writes on both sides.

Can I still serve documentation while GitBook is down?

Only if you already keep a copy. Teams using the Git sync workflow have the Markdown in their own repository and can publish it elsewhere temporarily. Without that, published pages are unavailable until the Public Content component recovers. This is the practical argument for docs-as-code over editing only in the hosted editor.

How much downtime does GitBook actually have?

GitBook publishes rolling uptime per component. For the three months to August 2026 its status page showed 99.86 percent for the GitBook App, 99.98 percent for Public Content and 100 percent for the Homepage. Those figures put typical downtime in hours per quarter rather than days, and they show the App failing more often than the public pages readers see.

How we measure this

We request GitBook'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 GitBook 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 GitBook 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