A computer that is always on and always connected, whose job is to answer requests from other computers.
Why it exists
Your product has to be reachable at three in the morning by someone you have never met, and the data everyone shares cannot sit on any single user's phone. A server exists to be that always-available machine: it stays powered and connected so it can receive requests and hand back answers around the clock. It is where the shared data and the real rules live, which is also why running out of server capacity during a spike takes the whole product down at once.
How it actually works
Your page has to live somewhere that is reachable at any hour. A server is that machine. When someone visits tiffinbox.com, their browser contacts this server and it hands back the page.
A server is not special hardware. It is an ordinary computer running software that listens for requests and responds. What makes it a server is the job, not the box.
A senior PM walks you through it
A junior PM, stuck
Ops posted that the server has been at 90% memory since the promo went live, and everyone reacted like it was obvious what that meant. I nodded along. I realize I do not actually know what the server is doing all night, or why memory creeping up is the thing to watch.
A server is just a computer that never turns off, sitting there answering requests one after another, including at 3am when nobody is watching. The clearest way to see what it does is its own log. Here are fourteen lines from the TiffinBox server, from the moment it booted through this morning's promo. Read the boot line, then watch what climbs.
TiffinBox server log, overnight into Friday 08:00
2026-03-06T02:00:04ZINFOserver listening on :443
2026-03-06T02:00:04ZINFOserver ready, memory 22%
2026-03-06T02:40:10ZINFOserver idle, 0 requests in last 10m
2026-03-06T03:07:15ZINFOcheckout POST /api/orders received user=u_88231 item=p_1042
2026-03-06T03:07:15ZINFOcheckout order created o_5507 in 42ms
Hearing "90% memory" as a status update rather than a warning. 90% means the headroom for the next spike is almost gone, and the Friday lunch peak is a far bigger load than this breakfast promo.
Assuming the server rests when traffic is low. The 03:07 line proves it answered an order in 42ms with nobody watching; a server is defined by being always available, not by being busy.
Blaming the code for a resource problem. Nothing in the code changed overnight; the promo brought load. The fix is capacity, not a bug ticket.
Skimming past the WARN lines. The server says it is fine (INFO) or nervous (WARN) in the level field, so the WARN lines are the only ones asking for attention, and they are the easiest to miss.
Reply to ops: "Reading the overnight log, memory sat around 22% all night and climbed to the 90% warning within minutes of the 08:00 promo, so this is a capacity headroom problem, not the code. Do we have enough room for the lunch peak, which is a bigger spike than breakfast?" You read a server's log as what it is, an always-on machine, and spotted the resource climbing toward its limit.
Where a PM meets this
Everything you ship runs on servers that someone pays for and maintains. "Server cost" and "server capacity" appear in planning for the rest of your career.
When traffic spikes and things slow down, the server is often what ran out of room.
Hear it in a meeting
"The server's been at 90% memory since the promo went live."