The !Uptime Command: Show How Long You've Been Live

What Does the !Uptime Command Do?

The !uptime command reports how long the current broadcast has been running. A viewer types it, and the bot replies with something like “The stream has been live for 3 hours 42 minutes.” It reads the actual start time of the broadcast from the platform, so the answer is accurate to the minute regardless of whether you remember when you hit Go Live.

Neither Twitch, YouTube Live nor Kick shows a running clock to viewers by default. The player shows that a stream is live, not when it started, and the only native hint is the VOD timeline — which most viewers never open and which doesn't exist at all if you have VODs disabled. That gap is why !uptime is one of the oldest and most universally installed chat commands: it fills in information the platform simply doesn't surface.

Unlike a static link command, this one needs live data. The bot has to know when the broadcast started, which means either an API call to the platform or its own record of when it saw the stream come online. That distinction sounds academic but it's the source of nearly every wrong answer an uptime command gives, and it's covered in detail further down.

The command's usefulness scales with how long you stream. On a 90-minute broadcast, nobody needs it. On a six-hour marathon, a subathon, or a charity stream where the total elapsed time is part of the event, it gets typed constantly — and it gives you a natural way to mark milestones without checking a clock mid-sentence.

Why Viewers Ask How Long You've Been Live

The most common reason is orientation after arriving. Someone lands on your channel from the directory, from a raid, or from a notification, and the first thing they want to know is where they are in the broadcast. Did they catch the start, or have they walked in on hour five of something with context they've missed? “Did I miss much?” is really a question about uptime, and a viewer who can answer it themselves settles into the stream faster than one who has to interrupt to ask.

Raids sharpen this. Forty people arrive at once, all with the same question, and none of them want to be the one who asks it. A single !uptime from any one of them — or from a mod welcoming the raid — answers it for the whole group, and it tells them something useful about what they've joined. A stream two hours in is settled and mid-flow; a stream twenty minutes in is still warming up and is a better moment to introduce yourself.

Regulars use it differently. For them uptime is a status check on you: how long have you been going, and should someone be telling you to take a break? Long-session streamers know this feeling — chat starts asking for uptime around hour five, and the number becomes a gentle collective nudge toward food, water and a screen break. Some streamers lean into it and write the response to acknowledge it directly.

Then there's the event case. Subathons, 24-hour charity streams and marathon runs make elapsed time part of the content. When the length of the broadcast is the thing, viewers check it the way they'd check a scoreboard, and an uptime command that returns a clean, readable number gets typed hundreds of times in a session. If that's your format, it's worth writing a response that celebrates the number rather than just stating it.

Finally, uptime is how a returning viewer decides whether to stay. Someone who checks in at hour six of a scheduled eight-hour stream knows they've got two hours of content ahead; someone who checks in at hour seven and a half might leave rather than get invested. That's not a reason to hide the number — it's a reason to pair the response with what's coming next, which costs you nothing and turns a stat into a reason to stick around.

How Bots Calculate Uptime (And Where It Goes Wrong)

There are two ways a bot can work out how long you've been live, and they disagree more often than you'd expect. The first is to ask the platform: Twitch's API exposes a started_at timestamp on the live stream object, and the bot subtracts that from the current time. This is the accurate method — it's true whether the bot was running when you went live, whether it restarted mid-stream, and whether you were away from your dashboard. The second method is for the bot to note the moment it first saw the channel go live and count from there. It requires no API access, and it's wrong whenever the bot joined late.

That second method is the cause of the classic complaint: uptime resets to zero mid-stream, or reports twenty minutes when you've been live for three hours. If your bot reconnects — a service restart, a network blip, a deploy on the bot provider's side — a session-based counter starts over. An API-based counter doesn't move at all, because the platform's record of when the broadcast started hasn't changed. When you're choosing a bot, this is a genuine differentiator for anyone who streams long sessions.

The other reliable source of wrong answers is you. Ending and restarting a broadcast resets the platform's started_at too, so if OBS crashes at hour four and you go live again, your uptime command will honestly report four minutes. There is no way around this — the platform genuinely started a new stream — but it's worth knowing before you accuse your bot of being broken. Twitch does keep a short grace window during which a reconnect can be stitched into the same stream, so a brief drop may not reset the clock; a longer outage will.

Multistreaming adds a wrinkle that most bots ignore entirely. If you go live on Twitch at 19:00, and your YouTube and Kick outputs come up thirty seconds later, you now have three different start times. A single-platform bot will report whichever one it happens to be reading, and a viewer on Kick can get an answer that's noticeably off from what a Twitch viewer sees. Any bot that runs commands across all three platforms at once has to decide which clock is authoritative — usually the earliest start across your outputs, since that's when the broadcast actually began from your point of view.

A few formatting notes worth getting right. Round sensibly: “3 hours 42 minutes” is readable, “3.7 hours” is not, and seconds are noise unless you're under a minute. Handle the offline case explicitly — a viewer typing !uptime in an offline chat should get “The stream is offline,” not an error or a stale number from last night. And set a global cooldown rather than a per-user one; during a raid, forty people typing the same command in ten seconds is exactly the scenario that turns a helpful command into a wall of identical bot messages. Thirty seconds globally is plenty, and it looks far better in a merged chat overlay where every platform's copy of the response would otherwise appear at once.