The One-Millisecond Update That Almost Melted Production

The alert came in at 2:13 a.m.

Arman’s phone buzzed on the nightstand with the familiar, unwelcome vibration that every developer learns to dread. The message was short and blunt:

Production CPU usage: 96%

He squinted at the screen. “That’s… not great.”

Five minutes later he was at his desk, hoodie half-zipped, staring at the monitoring dashboard like it had personally betrayed him. The graphs looked like mountains. CPU spikes everywhere. Memory climbing. Request latency stretching into the seconds.

The strange part was the traffic.

There wasn’t any.

The site had maybe twelve active users.

“Twelve people,” Arman said quietly, “should not require the power output of a small power plant.”

He opened the logs.

They weren’t helpful. Requests looked normal. No infinite loops in the backend. No database explosions. No obvious culprits.

Then he noticed something strange in the browser performance tab.

The frontend CPU usage was also sky-high.

That narrowed things down.

“Alright,” he muttered, opening the codebase. “Which one of you did something clever?”

The recent commits were small: a few CSS tweaks, a dependency update, and one innocent-looking message from a teammate named Kevin.

commit message:
improved date formatting

Arman sighed. “Kevin…”

He opened the diff.

The change was tiny. Just a utility function used across the app to display timestamps more nicely.

Before:

function formatTime(date) {
  return new Date(date).toLocaleString();
}

After:

function formatTime(date) {
  return new Date(date).toLocaleString();
}

setInterval(() => {
  document.querySelectorAll("[data-time]").forEach(el => {
    el.textContent = formatTime(el.dataset.time);
  });
}, 1);

Arman blinked.

“Interval… one?”

He counted the zeros again.

One millisecond.

The script was scanning the entire DOM one thousand times per second looking for timestamps to update.

And the page had a lot of timestamps.

Comments. Logs. Notifications. Chat messages. Audit history. Admin panels. Tooltips.

Arman opened the page and ran a quick check:

document.querySelectorAll("[data-time]").length

The console returned:

3,842

His laptop fan spun up immediately as the script started running.

The math settled in slowly.

Every millisecond the browser was scanning almost four thousand elements. That meant nearly four million DOM operations every second. Across every open tab. Across every user session.

Arman leaned back in his chair.

“That would do it.”

But something still bothered him.

The commit message said “improved date formatting.” Updating timestamps every millisecond was… excessive. Even by Kevin standards.

He opened Slack and searched for the conversation around the change.

Eventually he found it.

Kevin had asked a simple question earlier that day:

“How do we make timestamps update in real time?”

Someone had replied:

“Just use setInterval.”

Kevin had done exactly that.

Technically, the timestamps were updating in real time now. Extremely real time. Aggressively real time.

Arman changed the interval from 1 to 60000.

One minute.

He deployed the fix.

Within seconds the monitoring dashboard relaxed. CPU usage dropped from the red zone to something normal. The graphs slowly flattened like a storm passing out to sea.

He posted the resolution in the incident channel:

Root cause: Timestamp updater running every 1ms across thousands of elements.

Kevin responded almost immediately.

“Wait, is that bad?”

Arman stared at the message for a moment.

Then he replied:

“Only if you like electricity.”

A few seconds later Kevin answered again.

“Oh. I thought lower numbers were faster.”

Arman leaned back, closed the incident dashboard, and took a sip of cold coffee.

Somewhere in the codebase, the timestamps were still updating. Calmly now. Once per minute. The servers were quiet again, the fans had stopped screaming, and the infrastructure bill had likely dropped by several dollars per hour.

All because someone wanted the time to be a little more accurate. ⏱️💻

And from that day forward, every developer on the team learned an important lesson:

When someone says “real time,” it’s always worth asking how real.