In Karate, what does `karate.configure('readTimeout', 5000)` do, and when would you write that instead of a `* configure readTimeout = 5000` step?

middleshould knowfreq 52%

answer

same keys, two front doors
the config file has no steps in it
thirty seconds, both of them
a typo in the key throws

basics

~10 s

It does exactly what the configure step does; both hand the same key and value to the same parser. The JavaScript form is for places with no Gherkin step to write, above all karate-config.js.

solid answer

~40 s

karate.configure(key, value) is the JavaScript entry point to the same machinery the configure step uses: one function parses key names, and both routes call it. You reach for it in karate-config.js, which is a JavaScript file with no steps in it, and inside any JavaScript in a feature — * eval karate.configure('ssl', cfg) — when the value has to be computed or applied conditionally. readTimeout and connectTimeout are both 30000 ms by default, and Karate re-applies the change to the underlying HTTP client, so lowering one mid-scenario takes effect on the next request. An unrecognised key is not ignored: Karate throws unexpected 'configure' key: '<key>', so a typo such as readTimeOut fails loudly.

`karate.configure(key, value)` is the JavaScript entry point to the same machinery the `configure` step uses: one function parses key names, and both routes call it. You reach for it in `karate-config.js`, which is a JavaScript file with no steps in it, and inside any JavaScript in a feature — `* eval karate.configure('ssl', cfg)` — when the value has to be computed or applied conditionally. `readTimeout` and `connectTimeout` are both **30000 ms** by default, and Karate re-applies the change to the underlying HTTP client, so lowering one mid-scenario takes effect on the next request. An unrecognised key is not ignored: Karate throws `unexpected 'configure' key: '<key>'`, so a typo such as `readTimeOut` fails loudly.

code

javascript · 9 lines

javascript

function fn() {
  var env = karate.env || 'dev';
  karate.configure('connectTimeout', 5000);
  karate.configure('readTimeout', 10000);
  if (env === 'ci') {
    karate.configure('retry', { count: 10, interval: 500 });
  }
  return { baseUrl: 'https://api.' + env + '.test' };
}

go deeper

for a junior

Know that karate.configure(key, value) and the configure step are the same operation, and that the function form is what you write in karate-config.js.

for a middle

Be able to name the two timeout keys, say they are milliseconds with a 30000 default, and explain that an unknown key throws rather than being ignored.

for a senior

Judge which timeouts belong in the config file. A low connect timeout makes a bad host fail fast across the whole suite; a low read timeout quietly converts slow-service incidents into test failures.

for a principal

Decide how ambient HTTP settings are governed across many suites — which are fixed policy, which may be overridden per feature, and how a team discovers what is already set for them.

One parser, two front doors

Karate has exactly one place that understands configure key names, and both the Gherkin step and the JavaScript call arrive there. * configure readTimeout = 5000 is parsed into a key and an expression, the expression is evaluated, and the pair is handed over. karate.configure('readTimeout', 5000) skips the parsing and hands over the same pair. There is no second set of keys, no subset that only one form supports, and no difference in effect.

That matters for a practical reason: anything you read about a configure key applies unchanged to the JavaScript form, and vice versa.

Why the JavaScript form exists

There are two situations where a step is not available or not enough.

karate-config.js is JavaScript, not Gherkin. There is no step syntax in that file, so the only way to set ambient HTTP settings there is the function call. This is the dominant usage — timeouts, proxy and SSL settings are the classic examples.
The value or the decision is dynamic. A step is unconditional; a JavaScript call can sit behind an if. Inside a feature you can still reach it with * eval karate.configure(...) — Karate's own suite does this to install an mTLS keystore built from system properties.

A rough rule: use the step when the setting is a fixed part of the scenario's story, and the function when the setting is a consequence of something computed.

The timeout keys and their defaults

key	what it bounds	default
`connectTimeout`	establishing the TCP/TLS connection	30000 ms
`readTimeout`	waiting for the response once connected	30000 ms

Both are milliseconds, and both are generous on purpose — they are meant to stop a suite hanging forever, not to act as an assertion about latency. Two consequences follow:

Thirty seconds per call is a long time to wait for a host that is simply unreachable. Dropping connectTimeout to a few seconds in the config file is the usual reason people touch these keys at all: a wrong hostname then fails fast instead of stalling the suite.
Lowering readTimeout to police response time turns an infrastructure guard into a flaky assertion. If you care about latency, assert on it explicitly rather than by starving the client.

Changing a timeout takes effect immediately

The timeouts are baked into the HTTP client, not consulted per request, so Karate re-applies the configuration to the client when you change one. The observable behaviour is what you want: a configure readTimeout step partway through a scenario governs the calls that follow it, not just the next scenario.

Unknown keys throw — they are not ignored

The key switch has no permissive fallback. Anything it does not recognise raises unexpected 'configure' key: '<key>', and the key is matched exactly, case included. So:

karate.configure('readTimeOut', 5000) fails the run with that message rather than quietly doing nothing;
so does configure timeout = 5000, which is not a key at all;
and the failure surfaces at the step or at config-evaluation time, which is early and easy to read.

This is a deliberately strict design and a good thing to know, because the opposite assumption — "a typo in a configure key is silently ignored" — is a very common guess and it is wrong. Note that strictness applies to the key, not to the value: several keys accept only a particular shape and quietly ignore a value of the wrong type, which is a separate trap.

Which one wins when both are used

There is one stored value per key, and the last thing to run owns it. A suite that sets connectTimeout to 5000 in karate-config.js and then meets * configure connectTimeout = 30000 in a scenario sends that call with the larger value, because the step ran later. Reach is decided by where you put the call, never by which form you used:

config file, for a setting the whole suite should inherit;
a feature's Background, for a setting every scenario in that file needs;
one scenario, for a deliberate local exception.

So the JavaScript form is not "the global one" and the step is not "the local one" — a karate.configure call inside a scenario is exactly as local as a step, and a configure step would be exactly as global if there were a way to run it suite-wide. Reading it any other way leads people to hunt for a precedence rule that does not exist.

What to say in an interview

"They are the same operation. The function form exists because karate-config.js is JavaScript, so there is no step to write there, and because it can be called conditionally. Both timeouts default to thirty seconds, and an unrecognised key throws rather than being ignored."

## One parser, two front doors Karate has exactly one place that understands `configure` key names, and both the Gherkin step and the JavaScript call arrive there. `* configure readTimeout = 5000` is parsed into a key and an expression, the expression is evaluated, and the pair is handed over. `karate.configure('readTimeout', 5000)` skips the parsing and hands over the same pair. There is no second set of keys, no subset that only one form supports, and no difference in effect. That matters for a practical reason: anything you read about a `configure` key applies unchanged to the JavaScript form, and vice versa. ## Why the JavaScript form exists There are two situations where a step is not available or not enough. 1. **`karate-config.js` is JavaScript, not Gherkin.** There is no step syntax in that file, so the only way to set ambient HTTP settings there is the function call. This is the dominant usage — timeouts, proxy and SSL settings are the classic examples. 2. **The value or the decision is dynamic.** A step is unconditional; a JavaScript call can sit behind an `if`. Inside a feature you can still reach it with `* eval karate.configure(...)` — Karate's own suite does this to install an mTLS keystore built from system properties. A rough rule: use the step when the setting is a fixed part of the scenario's story, and the function when the setting is a consequence of something computed. ## The timeout keys and their defaults | key | what it bounds | default | |---|---|---| | `connectTimeout` | establishing the TCP/TLS connection | 30000 ms | | `readTimeout` | waiting for the response once connected | 30000 ms | Both are milliseconds, and both are generous on purpose — they are meant to stop a suite hanging forever, not to act as an assertion about latency. Two consequences follow: - Thirty seconds per call is a long time to wait for a host that is simply unreachable. Dropping `connectTimeout` to a few seconds in the config file is the usual reason people touch these keys at all: a wrong hostname then fails fast instead of stalling the suite. - Lowering `readTimeout` to police response time turns an infrastructure guard into a flaky assertion. If you care about latency, assert on it explicitly rather than by starving the client. ## Changing a timeout takes effect immediately The timeouts are baked into the HTTP client, not consulted per request, so Karate re-applies the configuration to the client when you change one. The observable behaviour is what you want: a `configure readTimeout` step partway through a scenario governs the calls that follow it, not just the next scenario. ## Unknown keys throw — they are not ignored The key switch has no permissive fallback. Anything it does not recognise raises `unexpected 'configure' key: '<key>'`, and the key is matched exactly, case included. So: - `karate.configure('readTimeOut', 5000)` fails the run with that message rather than quietly doing nothing; - so does `configure timeout = 5000`, which is not a key at all; - and the failure surfaces at the step or at config-evaluation time, which is early and easy to read. This is a deliberately strict design and a good thing to know, because the opposite assumption — "a typo in a configure key is silently ignored" — is a very common guess and it is wrong. Note that strictness applies to the **key**, not to the value: several keys accept only a particular shape and quietly ignore a value of the wrong type, which is a separate trap. ## Which one wins when both are used There is one stored value per key, and the last thing to run owns it. A suite that sets `connectTimeout` to 5000 in `karate-config.js` and then meets `* configure connectTimeout = 30000` in a scenario sends that call with the larger value, because the step ran later. Reach is decided by **where** you put the call, never by **which form** you used: - config file, for a setting the whole suite should inherit; - a feature's `Background`, for a setting every scenario in that file needs; - one scenario, for a deliberate local exception. So the JavaScript form is not "the global one" and the step is not "the local one" — a `karate.configure` call inside a scenario is exactly as local as a step, and a `configure` step would be exactly as global if there were a way to run it suite-wide. Reading it any other way leads people to hunt for a precedence rule that does not exist. ## What to say in an interview "They are the same operation. The function form exists because `karate-config.js` is JavaScript, so there is no step to write there, and because it can be called conditionally. Both timeouts default to thirty seconds, and an unrecognised key throws rather than being ignored."

What happens if you misspell a Karate configure key, for example `configure readTimeOut = 5000`?
The run fails with `unexpected 'configure' key: 'readTimeOut'`. Key matching is exact and case-sensitive, and the switch has no permissive default branch, so there is no silent no-op to hunt for. It is worth contrasting this with the values: several keys accept only one shape and ignore anything else without complaint, so a wrong key is loud while a wrong value type often is not.
What is the difference between `connectTimeout` and `readTimeout` in Karate, and which one do you usually lower first?
`connectTimeout` bounds establishing the connection; `readTimeout` bounds waiting for the response after it is established. Both default to 30000 ms. `connectTimeout` is normally the one to lower, because a wrong or unreachable host otherwise costs thirty seconds per call across the whole suite. Lowering `readTimeout` to police latency is a poor substitute for asserting on response time directly.

saying these in an interview costs you the question

Says the JavaScript form supports a different set of keys
Thinks a misspelled configure key is silently ignored
Believes timeouts are in seconds rather than milliseconds
Uses readTimeout as a latency assertion for the endpoint
Assumes a timeout change only applies from the next scenario

In Karate, what does `karate.configure('readTimeout', 5000)` do, and when would you write that instead of a `* configure readTimeout = 5000` step?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

One parser, two front doors

Why the JavaScript form exists

The timeout keys and their defaults

Changing a timeout takes effect immediately

Unknown keys throw — they are not ignored

Which one wins when both are used

What to say in an interview

▾common follow-ups2 questions

▾red flags5 flags

One parser, two front doors

Why the JavaScript form exists

The timeout keys and their defaults

Changing a timeout takes effect immediately

Unknown keys throw — they are not ignored

Which one wins when both are used

What to say in an interview

answer

go deeper