Deployment Log
Definition
A deployment log has two parts that people often confuse. The history is the list of publishes: a timestamp, an author, a version identifier, the files that changed and whether the publish succeeded. The build output is the text a build step printed while running — packages installed, files written, warnings raised. The history answers when something changed; the build output usually answers why it broke. Warnings in build output are worth more attention than they get, because a build that exits successfully can still have skipped a missing image or fallen back to a default that nobody wanted. On a host with version history, the log and the rollback are the same feature seen from two sides: the entries are both a record and a set of restore points.
Why It Matters
Most breakages correlate with a change, and the log is what turns a guess into a fact. If a page broke between 14:00 and 14:30 and the log shows a publish at 14:07, you are one click from a fix rather than an hour into reading markup. Without a log, small teams lose real time to the question of who last touched it, and the answer is often nobody remembers. Retained logs also settle later arguments: when a client asks why a document changed in March, an entry naming the person, the time and the file is the end of the discussion. And a log makes it possible to tell a slow drift from a sudden break, which are different problems with different fixes.
How It Works
Read the history in reverse from the moment the symptom appeared, and compare timestamps against your monitoring rather than against when someone noticed. Then open the build output for that specific publish and search it for the word warning before the word error, since the first error is often a consequence of something that only warned. Check what the publish actually produced, not what it intended: an empty or half-populated output directory is the classic cause of a site that returns nothing while every step reported success. Keep the log long enough to be useful — 90 days covers nearly every question worth asking about a small site, and log retention limits vary by plan, so know yours before you need it. Write a short note with each publish, because the entry that says fixed typo in pricing table is worth ten that say update.
Real-World Example
A software team publishes its documentation at wrenfield-docs.99helpers.site from a build that runs on every merge. Search stops finding anything one Wednesday, though every page looks fine. The deployment log shows a publish at 11:42 whose build output carried a warning that the search index file was not found, and the step after it exited zero anyway. Rolling back restores search immediately; the real fix, applied later, is to make the build fail loudly when that file is missing rather than publishing a site that is quietly incomplete.
Common Mistakes
- ✕Only reading the log when a publish fails outright — the expensive incidents come from publishes that succeeded and shipped the wrong output
- ✕Ignoring warnings because the build exited successfully, which is how a missing asset or a silent fallback reaches the live site
- ✕Writing every entry as update, so the history records that something changed while telling you nothing about what
- ✕Assuming logs are kept forever — retention is usually capped by plan, and the entry you want is often just past the edge
Related Terms
Incident Response
What you do between noticing that something is broken and confirming it is fixed. For a small site it is a short, boring sequence agreed in advance so that nobody has to invent one under pressure.
Smoke Test
A quick check after publishing that the obvious things still work. It is not thorough by design — its job is to catch the catastrophic failure in two minutes, not to find every bug.
Log Retention
How long you keep request logs, deployment records and visitor data before deleting them or rolling them up. It is a decision worth making deliberately rather than a default to leave alone.
Deployment
A deployment is the act of putting a new version of a site or file where the public can reach it. It is the moment the version you have been working on becomes the version visitors get.
Build Step
A build step is the command that turns source files into the folder a web server can actually serve. It runs before publishing, produces an output folder, and is not part of the live site.
Put a file online in seconds
Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.
Host a file free →