Serial.parseInt() or readString() makes the sketch slow

These functions wait up to a second for more characters. Shorten the timeout, or read until a newline.

What the message means

The default timeout is 1000 ms. parseInt and readString wait for it when the last character has no end marker.

Fix it in this order

Call Serial.setTimeout(20) in setup().
Send a newline at the end of each message and use readStringUntil('\n').
Check Serial.available() before reading.
For fast loops read one byte at a time and build the message yourself.
Make sure the serial monitor sends a newline if your code expects one.

Why it happens

Functions such as parseInt and readString read characters until they see something that ends the value, or until a timeout passes. When the last character is a digit with nothing after it, the function cannot know the number is finished, so it waits out the timeout before it returns. The page gives the default as 1000 ms.

A newline at the end of every message gives the reader a clear end marker, so it can return at once. Shortening the timeout is the other route, but a timeout that is too short can cut a message that arrives slowly.

If you see this, do this

You see	Do this
One second pause after each command	Timeout. Shorten it.
Command never completes	No end character.

delay and millis, serial monitor shows nothing.

Last reviewed: November 2026. These are the usual causes and the order that finds them fastest. Test on your own board; clones and cables differ.

Why this happens

Functions such as parseInt, parseFloat and readString are built on top of a timed read. They wait for characters up to a timeout, which is 1000 ms by default. parseInt keeps reading digits until it meets a character that is not part of a number. If your message ends with a digit and nothing follows, there is no such character, so the function waits out the full timeout.

readString has no end marker at all. It reads until the timeout passes, so every call costs the whole timeout. Also note that parseInt returns 0 when it times out without finding digits, so you cannot tell a real zero from a timeout.

How to confirm the cause

Print millis() before and after the call. A difference close to 1000 ms is the timeout.
In the serial monitor, check the line-ending option. With ‘No line ending’ the message has nothing after the last digit.
Print Serial.available() before calling the function, to see how many characters have arrived.
Call Serial.setTimeout(50) in setup() and compare the delay.
If a long message is cut after you shortened the timeout, the timeout is now shorter than the gap between characters.

Worked example

Measure the delay, and the version that reads up to a newline and returns at once.

unsigned long t0 = millis();
int v = Serial.parseInt();
Serial.print(v);
Serial.print(" took ");
Serial.print(millis() - t0);
Serial.println(" ms");

char buf[12];
int n = Serial.readBytesUntil('\n', buf, sizeof(buf) - 1);
buf[n] = 0;
int value = atoi(buf);

Common mistakes

Setting the timeout to 0, which can return before the characters arrive.
Leaving the line-ending option at ‘No line ending’.
Forgetting that parseInt leaves the ending character in the buffer, so the next read must expect it.
Using delay() in the same loop, so incoming characters pile up.
Using String in a loop on a board with little RAM.

If this did not fix it

A baud rate mismatch, which garbles the characters.
The 64-byte receive buffer on an Uno overflowing when the loop is slow.
A slow link, such as some Bluetooth modules, which needs a longer timeout.

Serial.parseInt() or readString() makes the sketch slow: the 1 second timeout