In React Native NetInfo, what do reachabilityUrl and the other reachability options in NetInfo.configure control, and why point them at your own API?

seniorshould knowfreq 22%

answer

whose server answers the probe?
HEAD, expect 204, by default
60 s when up, 5 s when down
Android prefers the OS verdict
configure once, at startup

basics

~20 s

They configure NetInfo's own HTTP probe: reachabilityUrl, method and headers, a reachabilityTest on the response, polling intervals and a request timeout. Pointing it at your API's health endpoint makes 'reachable' mean 'our backend answers'. Call NetInfo.configure once at startup.

solid answer

~40 s

When the platform does not report internet reachability natively, which is iOS by default, or when useNativeReachability is false, NetInfo sends its own probe: a HEAD request to reachabilityUrl (default: a Google generate_204 URL) and passes the response to reachabilityTest, which by default checks for status 204. It re-probes every reachabilityLongTimeout (60 s) while reachable and every reachabilityShortTimeout (5 s) while not, aborting a probe after reachabilityRequestTimeout (15 s); reachabilityShouldRun can switch probing off. Pointing the probe at your own health endpoint means reachability answers the question the app cares about, and it avoids depending on a third-party host that some networks block. I call NetInfo.configure once at startup, because it tears down the singleton and stops existing listeners, and I avoid useNetInfo(config), which calls configure on every render.

When the platform does not report internet reachability natively, which is iOS by default, or when `useNativeReachability` is `false`, NetInfo sends its own probe: a `HEAD` request to `reachabilityUrl` (default: a Google `generate_204` URL) and passes the response to `reachabilityTest`, which by default checks for status `204`. It re-probes every `reachabilityLongTimeout` (60 s) while reachable and every `reachabilityShortTimeout` (5 s) while not, aborting a probe after `reachabilityRequestTimeout` (15 s); `reachabilityShouldRun` can switch probing off. Pointing the probe at your own health endpoint means reachability answers the question the app cares about, and it avoids depending on a third-party host that some networks block. I call `NetInfo.configure` once at startup, because it tears down the singleton and stops existing listeners, and I avoid `useNetInfo(config)`, which calls `configure` on every render.

code

typescript · 12 lines

typescript

import NetInfo from '@react-native-community/netinfo';

// index.ts, before the root component registers
NetInfo.configure({
  reachabilityUrl: 'https://api.example.com/health',
  reachabilityMethod: 'HEAD',
  reachabilityTest: async (response) => response.status === 204,
  reachabilityLongTimeout: 60 * 1000,
  reachabilityShortTimeout: 10 * 1000,
  reachabilityRequestTimeout: 8 * 1000,
  useNativeReachability: false, // same definition of 'reachable' on iOS and Android
});

go deeper

for a junior

Recall that NetInfo can check internet access by calling a URL, set with reachabilityUrl, and that configuration happens through NetInfo.configure.

for a middle

Explain the defaults: HEAD, expect 204, re-probe every 60 s when up and 5 s when down, 15 s timeout, and that Android normally uses the OS verdict.

for a senior

Point the probe at your own health endpoint with a matching reachabilityTest, plan for its server load, and configure exactly once because configure resets listeners.

for a principal

Decide what 'online' means for the product, a generic internet check or your backend's health, and weigh consistent cross-platform probing against its load and battery cost.

When the probe runs at all

NetInfo 12 gets isInternetReachable from one of two sources:

Native reachability. If the native module reports a boolean and useNativeReachability is true (the default), NetInfo uses it. On Android the native module does report one, based on the OS marking the network as validated, so by default no probe runs on Android.
NetInfo's own probe. Otherwise, which is the default situation on iOS, NetInfo performs HTTP checks from JavaScript whenever the device reports a connection.

Setting useNativeReachability: false forces the probe on every platform, which is useful when you want "reachable" to mean the same thing everywhere.

The options

Option	Default	What it controls
`reachabilityUrl`	`https://clients3.google.com/generate_204`	The URL the probe requests
`reachabilityMethod`	`'HEAD'` (or `'GET'`)	HTTP method of the probe
`reachabilityHeaders`	`{}`	Headers sent with the probe
`reachabilityTest`	status `=== 204`	Async function deciding reachable from the `Response`
`reachabilityLongTimeout`	60 s	Delay before re-probing while reachable
`reachabilityShortTimeout`	5 s	Delay before re-probing while unreachable
`reachabilityRequestTimeout`	15 s	Probe aborted and counted as unreachable after this
`reachabilityShouldRun`	`() => true`	Return `false` to skip probing (value becomes `false`)
`useNativeReachability`	`true`	Prefer the platform's own verdict when it provides one

Why point it at your own API

The default probe answers "can this phone reach a Google endpoint?". That is not always the question:

Relevance. The field-inspection app needs to know whether its backend answers. A health endpoint such as https://api.example.com/health returning 204 gives exactly that.
Blocked hosts. Some corporate, school or national networks block or intercept particular third-party hosts, so the default probe can report unreachable while your API works.
Control. With reachabilityTest you can accept a 200 and inspect headers, and with reachabilityHeaders you can tag probe traffic so the backend can exclude it from analytics.

The costs to plan for:

Server load. Every active iOS client (or every client, with useNativeReachability: false) probes at least once a minute, and every 5 seconds while it believes it is offline. Keep the endpoint trivial and cacheable at the edge.
Battery and data. reachabilityShouldRun can disable probing when it is not needed, for example while the app is not in the foreground.

configure: once, and early

NetInfo.configure(options) merges your options with the defaults, tears down the current singleton and creates a new one, which stops listeners added before the call. On iOS it also forwards the configuration to the native module. Therefore:

Call it once, at startup, before components subscribe.
Do not pass a configuration to useNetInfo(configuration) casually: the hook calls configure on every render, repeatedly resetting the singleton, including the subscription the hook itself registered.
If one screen genuinely needs different settings, use useNetInfoInstance(isPaused, configuration), which runs an isolated manager and leaves the singleton alone.

Designing the health endpoint

If the probe targets your backend, the endpoint deserves a little design:

Cheap and dependency-free. It should answer from the edge or the web tier without touching the database; the question is "can the app reach us", not "is every dependency healthy".
Status the test expects. Return 204 for the default reachabilityTest, or change the test to accept 200.
No authentication. The probe runs before and after login and must not fail because a token expired.
Exempt from rate limits. Probes every 5 seconds from clients that believe they are offline can trip per-IP limits behind shared NAT.
Cache headers. NetInfo sends the probe with cache: 'no-cache', but intermediaries should still not serve a stale success.

What interviewers probe

They want to hear that reachability comes from the OS on Android and a JavaScript HTTP probe on iOS, what the probe does by default (HEAD, expect 204, 60 s / 5 s cadence), why you would point it at your own endpoint, and the operational trap that configure resets listeners.

## When the probe runs at all NetInfo 12 gets `isInternetReachable` from one of two sources: - **Native reachability.** If the native module reports a boolean and `useNativeReachability` is `true` (the default), NetInfo uses it. On Android the native module does report one, based on the OS marking the network as validated, so by default **no probe runs on Android**. - **NetInfo's own probe.** Otherwise, which is the default situation on iOS, NetInfo performs HTTP checks from JavaScript whenever the device reports a connection. Setting `useNativeReachability: false` forces the probe on every platform, which is useful when you want "reachable" to mean the same thing everywhere. ## The options | Option | Default | What it controls | |---|---|---| | `reachabilityUrl` | `https://clients3.google.com/generate_204` | The URL the probe requests | | `reachabilityMethod` | `'HEAD'` (or `'GET'`) | HTTP method of the probe | | `reachabilityHeaders` | `{}` | Headers sent with the probe | | `reachabilityTest` | status `=== 204` | Async function deciding reachable from the `Response` | | `reachabilityLongTimeout` | 60 s | Delay before re-probing while reachable | | `reachabilityShortTimeout` | 5 s | Delay before re-probing while unreachable | | `reachabilityRequestTimeout` | 15 s | Probe aborted and counted as unreachable after this | | `reachabilityShouldRun` | `() => true` | Return `false` to skip probing (value becomes `false`) | | `useNativeReachability` | `true` | Prefer the platform's own verdict when it provides one | ## Why point it at your own API The default probe answers "can this phone reach a Google endpoint?". That is not always the question: 1. **Relevance.** The field-inspection app needs to know whether *its* backend answers. A health endpoint such as `https://api.example.com/health` returning `204` gives exactly that. 2. **Blocked hosts.** Some corporate, school or national networks block or intercept particular third-party hosts, so the default probe can report unreachable while your API works. 3. **Control.** With `reachabilityTest` you can accept a `200` and inspect headers, and with `reachabilityHeaders` you can tag probe traffic so the backend can exclude it from analytics. The costs to plan for: - **Server load.** Every active iOS client (or every client, with `useNativeReachability: false`) probes at least once a minute, and every 5 seconds while it believes it is offline. Keep the endpoint trivial and cacheable at the edge. - **Battery and data.** `reachabilityShouldRun` can disable probing when it is not needed, for example while the app is not in the foreground. ## configure: once, and early `NetInfo.configure(options)` merges your options with the defaults, **tears down the current singleton** and creates a new one, which **stops listeners added before the call**. On iOS it also forwards the configuration to the native module. Therefore: - Call it **once, at startup**, before components subscribe. - Do not pass a configuration to `useNetInfo(configuration)` casually: the hook calls `configure` on **every render**, repeatedly resetting the singleton, including the subscription the hook itself registered. - If one screen genuinely needs different settings, use `useNetInfoInstance(isPaused, configuration)`, which runs an isolated manager and leaves the singleton alone. ## Designing the health endpoint If the probe targets your backend, the endpoint deserves a little design: - **Cheap and dependency-free.** It should answer from the edge or the web tier without touching the database; the question is "can the app reach us", not "is every dependency healthy". - **Status the test expects.** Return `204` for the default `reachabilityTest`, or change the test to accept `200`. - **No authentication.** The probe runs before and after login and must not fail because a token expired. - **Exempt from rate limits.** Probes every 5 seconds from clients that believe they are offline can trip per-IP limits behind shared NAT. - **Cache headers.** NetInfo sends the probe with `cache: 'no-cache'`, but intermediaries should still not serve a stale success. ## What interviewers probe They want to hear that reachability comes from **the OS on Android and a JavaScript HTTP probe on iOS**, what the probe does by default (**`HEAD`, expect `204`, 60 s / 5 s cadence**), why you would **point it at your own endpoint**, and the operational trap that **`configure` resets listeners**.

You configure a custom reachabilityUrl, but Android devices never hit it. Why?
With the default `useNativeReachability: true`, NetInfo accepts the boolean Android's native module reports from the OS's validated-network check, so it never runs its JavaScript probe there. Set `useNativeReachability: false` to probe your URL on Android as well.
After a settings screen calls NetInfo.configure, the offline banner stops updating. Why?
`configure` tears down the global state manager and creates a new one, which stops every listener registered before the call, including the one behind the banner. Configure once at startup, or use `useNetInfoInstance` for screen-specific settings.
What happens to isInternetReachable when reachabilityShouldRun returns false?
NetInfo skips the probe and sets the value to `false`, so a banner keyed on `=== false` would show offline. Use it only when you also stop showing reachability-driven UI, for example while the app is in the background.

saying these in an interview costs you the question

A custom reachabilityUrl is always used on Android too.
The default probe is a GET request that accepts any 2xx response.
NetInfo probes reachability once at launch and never again.
NetInfo.configure can be called anywhere without affecting existing listeners.
Pointing the probe at your own API costs nothing on the server.

In React Native NetInfo, what do reachabilityUrl and the other reachability options in NetInfo.configure control, and why point them at your own API?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

When the probe runs at all

The options

Why point it at your own API

configure: once, and early

Designing the health endpoint

What interviewers probe

▾common follow-ups3 questions

▾red flags5 flags

When the probe runs at all

The options

Why point it at your own API

configure: once, and early

Designing the health endpoint

What interviewers probe

answer

go deeper