The night the system went down

When the system stops, you realise how much of your work depends on it and how well prepared you are to carry on.

In September 2026 I was on my first night of training at the hotel. I had come to learn the night processes. A little after midnight, the hotel system became unavailable because of an update, and it stayed that way for about five hours, until close to morning.

This is the only scene in this series that is not a picture. It happened, and I was there.

What I have and what I do not

What I have: the first night of training, the system unavailable for hours because of an update, the practical training that could not take place normally, and the explanation from the colleague who was training me that the practical part would continue on the following shift.

What I do not have: whether there was an official fallback procedure and whether it was used that night. What information the colleagues could use without the system, and whether it was written down in an approved document. The official notification chain and the communication with the departments. What was verified when the system came back, and whether any discrepancies remained.

And one distinction that has to be stated clearly: it was an interruption because of an update. I have no evidence that it was an unexpected fault. The title of this essay says “went down”, but that night was not a breakdown. It was something more ordinary, and for that reason more useful to understand.

Five hours of waiting

For most of that time I stood waiting and watching. The experienced colleague could explain the work to me, but could not show it to me. The processes I had come to learn lived on the screen, and the screen was not there.

It was not a dramatic night. Nobody ran. But it was a lesson I had not planned: how large the part of my work is that does not exist without the system. Not only the work that is done in it, but also the way it is learned. A new receptionist learns by watching someone click, fill in, check. When there is nowhere to click, only the explanation is left, and the explanation is not enough for a process you have never seen.

In How I built Front Desk Control I wrote about the period of the September trainings and about the need I had to organise the information into a clear structure. That night was, in a way, the beginning of that need.

When many processes depend on one system, its interruption affects not only the way people work, but also the way they learn.

What the team knew

In the first essay of this series I promised an essay about “the night the system went down and we saw what the team really knew”. I have to say honestly that I did not see that.

I was in training, and I relied on the colleague. I do not know what information was used without the system, nor whether it was written down anywhere. I will not claim that the staff kept all the necessary information in their heads, because I do not know, and because it is exactly the kind of sentence that sounds good and that I cannot prove.

What I can say is smaller. From where I was, a newcomer on the first night, I had no way of knowing what is done when the system is not there. I did not know where the procedure was, nor whether there was one. And that, for me, is the real finding of that night: not what the team knew, but what I did not know, and what nobody had any reason to tell me before it happened.

Coming back is not the end

I do not know what was checked that night when the system came back. But there is a principle I would keep.

The technical return of the system is not the same as the end of the incident. The screen can be there again, and there can still be work that should have been done during the hours when it was not, issues left pending, information that had to be entered. Before anyone says that everything is normal, it has to be confirmed, according to the authorised procedures, that the work can continue normally and that the open issues have an owner.

It is the same thing I wrote in The report a machine wrote about closing the day: the system that says “ready” does not know whether the day still has something open.

The system coming back is not the end of the incident.

Communication

The only communication I can confirm from that night is the one between me and the colleague: why we could not continue with the practical part, and when it would resume. About the official notification chain I know nothing.

The principle I stand by is simple, and it matters more at night than during the day: during an interruption, communication has to be clear, coordinated, and done only by the authorised people. An interruption is the moment when everyone wants to say something, and when a wrong word to the wrong person costs more.

Five things to know before the shift

What I would do differently today has nothing to do with that night. It has to do with the days before it. I would give more importance to preparation before the shift, and I would want to know five things:

1. Where the official business continuity procedure is.
2. Which responsibilities I can carry out within my role during an interruption. And which not.
3. Whom I should turn to for help or decisions.
4. How the open issues are documented and handed over, without breaching confidentiality.
5. How it is confirmed that operations have resumed normally.

These are things I would recommend preparing and learning in advance, not procedures I applied that night. And I would add one thing to the training of every newcomer: not only how to work with the system, but what is done on the day the system is not there. Because the newcomer is the one who knows the least, and the one with the least chance to ask.

A prepared operation is not one that pretends the system will never stop. It is one that knows how to keep responsibility and the continuity of the work when the system stops.

When the system stops

The card below is to be filled in on an ordinary day, before the shift: where the continuity procedure is, what you can do within your role, whom you turn to, how you hand over the open issues, and how it is confirmed that operations have resumed. On the night you need it, you will not have time to look for it. Shift Handover keeps the open issues in one place the next shift can find, even when they arose during the hours without the system.

When the system stops, you realise how much of your work depends on it, and how well prepared you are to carry on.