A Simple Shutdown Routine for Ending a Remote Workday

The note that cost me a day

A while ago I was building a booking page for a small business client, working with a designer who lived eight hours behind me. At about five on a Thursday I hit a question only she could answer: what the empty state should look like when a customer has no upcoming bookings. I wrote "waiting on design for empty states" in my notes, closed the laptop, and felt organised.

The next morning there was no answer, because I had never asked. I sent the question at 09:15, which was 01:15 for her. She replied at half past five my time, cheerfully and in detail, and by then my day was over. One sentence I could have sent in ninety seconds the evening before had turned into a full day of working around a gap.

That is the reason the shutdown routine below has an order, and why one particular step sits where it does. Most shutdown advice treats the end of the day as a mood: wind down, reflect, be kind to yourself. I treat it as ten minutes of operational work with a fixed sequence, because the sequence is what stops small, expensive mistakes like that one.

Nothing at home tells you to stop

An office gives you an edge without asking. People stand up, the lights in the meeting rooms go off, you leave. At a kitchen table none of that happens. The laptop stays visible, one message turns into another forty minutes, and the evening becomes a long grey stretch of half working.

The second cost arrives the next morning. Without a clean stop you start with yesterday's tabs, a stale idea of what matters, and fifteen minutes spent reconstructing where you were. You pay for the missing edge twice: once in the evening you did not quite have, and again in the morning you spent catching up with yourself.

Start ten minutes before you mean to stop

If you want to be done at 17:00, the routine starts at 16:50. This is the single change that makes everything else work, and it is the one people resist most, because it feels like giving away ten minutes of real work.

Run it at 17:00 instead and two things happen. You are already tired, so writing anything feels optional. And you have spent the last twenty minutes starting work that cannot finish, which is how "one small thing" becomes 18:30. I put a recurring calendar event at 16:50 called "shutdown" and treat it like a call with someone I do not want to keep waiting.

Diagram

The eight steps

1. Stop mid-task and write the resume cue. One minute. Save the file, stop the timer, and write the next physical action for whatever is unfinished. Do this before you feel done. If you wait for a natural stopping point, the natural stopping point will be at seven.

2. Write what is done. Two minutes. Link the result instead of describing it. "Invoice tax line is on staging, sample in ticket 441" is a done line. "Worked on invoices" is a diary entry, and nobody, including you tomorrow, can check it.

3. Separate open from blocked. One minute. Open means you can carry on tomorrow without anyone else. Blocked means you cannot, and someone else is the reason. Merging the two into one list is how a blocker sits unmentioned for three days while you quietly do other things.

4. Send the blocker asks now. Two minutes. This is the step I skipped that Thursday, and it is the most valuable one in the list. Recording "waiting on design" helps nobody. Send the actual message: name the decision you need, attach the thing they need to look at, and give a real date. If it goes out tonight, there is a decent chance the answer is waiting when you start, especially if the other person works hours behind yours. How to report blockers without being passive goes further on wording.

5. Choose tomorrow's first action. Two minutes. One line, with a verb, an object and a location, small enough to start cold. Plan it now because right now you still remember what you were doing, and in fourteen hours you will not.

Weak: "Continue portal." Usable: "Open portal.css, reproduce the overdue row overlap at 375px, compare against design frame 12."

6. Name one thing that is explicitly not tomorrow. Thirty seconds. Writing down what you are dropping stops tomorrow's plan from quietly becoming a copy of everything still open. It also stops that thing nagging at you over dinner, which is a nice side effect I did not expect.

7. Close the work surfaces. Two minutes. Close the work browser profile, quit chat, put away anything with client details on it, and move the laptop out of the evening space if you can.

8. Do something physical. Turn off the desk lamp, push the chair in, step outside for two minutes. It has to be small enough that you still do it on a bad day, which rules out anything involving trainers.

What a finished note looks like

• Done: invoice tax line on staging, link in ticket 441
• Open: customer portal overdue-label colour
• Blocked: need design approval on empty states by Thursday, asked in ticket 441
• Tomorrow's first action: open portal.css and reproduce the overdue row at 375px
• Not tomorrow: renaming the invoice helper functions

Five lines. They carry the state of the work, the question that is already out waiting for an answer, the restart point, and one deliberate exclusion. If a teammate might pick this up instead of you, they need more than five lines, and leaving work someone else can continue covers that fuller version. If the note goes to a client or a manager, shape it as an end-of-day status update instead of pasting your private shorthand.

Why the order is fixed

It can look fussy to insist on writing the done list before the blocker ask, or closing chat only after choosing tomorrow's action. I insist anyway, because each step depends on the one before it, and because tired people take the path of least resistance.

Writing done first warms up your memory of the day, which makes the open and blocked lists more honest. Separating blocked from open is what reveals the asks you need to send. Sending the asks before closing the tools is the whole point: once chat is closed, nobody reopens it at 16:58 to send one more message, so the ask has to happen while it is still open. And the physical step comes last because once the lamp is off, the day is over, and anything not captured stays uncaptured.

I tried running it in a looser order for a few weeks, on the theory that the content mattered more than the sequence. The blocker asks were the first thing to go.

The blocker asks were the first thing to go.

Mistakes I made building it

My first version had fourteen steps, including a short written reflection on what went well. It lasted nine working days. Anything longer than about ten minutes gets abandoned the first time a week goes badly, which is exactly the week you need it.

I also used to copy every open task into tomorrow. A plan with eleven items is an inventory, and tomorrow ignores inventories. Three at most, one of them clearly the main one.

I wrote reminders instead of actions. "Look at the CSS thing" cost me ten minutes the next morning working out which CSS thing. If the line needs interpreting, it is a reminder.

And I let the routine turn into a verdict on the day. Noting what did not finish, and why, is useful. Scoring yourself is not, and turning the shutdown into a daily performance review is the fastest way to start skipping it on the days that went badly.

Bad days and late days

The routine runs on bad days too, and those are the days it earns its keep. If the main task slipped, write an honest done line, shrink tomorrow's first action, and stop. Skipping the shutdown because the day felt weak guarantees that tomorrow starts weaker. If the day went sideways before lunch, recovering a workday after losing focus ends with this same close.

Sometimes work genuinely has to continue: a deadline, a broken deploy, a client launch. The rule I use is that the extension gets its own edges. Decide the new stop time before you start, name the narrow outcome you are going for, and tell whoever is affected. At the new stop, run a shortened version: capture, send, set tomorrow's action, close. An open-ended second session with no shutdown is how one late night becomes a late week.

On Fridays I add one line about what nobody should need from me over the weekend, and where to look if they do. When I am doing client work, the last two minutes also include logging the time while I still remember it, because reconstructing hours on Monday is guesswork dressed up as accounting.

What the morning gets out of it

The payoff of step five is that the next morning needs no decision. You sit down, read one line, and start. A morning routine can be short precisely because the previous evening did the thinking, which is the shape structuring a remote workday builds around. For code specifically, restarting where you left off adds branch names and test commands to that one line.

Keep the note wherever you will actually read it tomorrow: the ticket, the bottom of the working doc, or one daily note linked from the task. A beautiful note in a place you never open is worse than a scrappy one on the ticket.

If you only take one step from this, take step four. The lost evening gets all the attention, but the costlier failure at the end of a remote day is quieter: the question you meant to ask and did not, sitting in your notes while the person who could answer it gets through a whole working day without hearing from you.