Operations journal

This section lists the tasks on this page.

The Operations tab needs the role support_admin or higher. For roles, see People and roles. See What is Deployment Manager for the tool itself.

To open the journal:

This section describes the Operations tab and its five views of the journal.

Every action taken through Deployment Manager is written as one journal row. The row says who did it, on which installation, and how it ended. The Operations tab (support_admin and above) reads that journal through five views. All five share one filter bar with two filters:

A filter may get an unknown value. Examples are an installation name that does not exist, or an outcome that is not in the list. The screen refuses such a value and gives a clear reason. It does not show a silently empty list. An empty screen caused by a typo must never look like "nothing happened".

This section describes the Records view, what it can answer, and its exports.

Records is the journal with nothing combined. It has one row per action. You can filter on:

Rows are append-only. Nothing here is ever edited or deleted. This is what makes the journal a record and not a status board.

What it can answer: what was done, by whom, on which installation, when, and with what outcome. It goes back as far as the journal has been kept. What it cannot answer:

For example, a change made by hand on a server leaves no row here at all. Only its effect shows, in Health or Diagnostics.

"As far as the journal has been kept" is the most important limit on this screen. Nothing deletes rows from the journal. It is permanent by design. But it only begins at the point where it was first written. Some of its columns began even later. An installation deployed to a customer before that point has no rows. It then looks as if it reached no step at all, not like a production system that is a year old. Compare any figure from the journal with the date the screens state. Read "no history" as "nobody recorded any". Some other records are removed on their own schedules. The assistant’s transcripts are removed after a month. Several telemetry tables are removed after three months. The journal is not among them.

What a row can and cannot contain. The list of actions is fixed. Each action declares which details it may carry. So the journal cannot silently get a new field that holds something it should not. Those details are names, counts and identifiers only, never values. An edit to a server’s configuration records which settings changed, not their new values. Writing secrets records how many secrets were written.

One deploy is several requests, joined into a chain. The panel creates an identifier when it opens. It sends this identifier on each request of that deploy. Records can then rebuild a whole deploy from its parts in one action. A row with no such identifier happened outside a panel series.

There are two different exports. They are kept as two separate actions on purpose, not as one export with a toggle:

The internal export needs an explicit time window. It does not default to "everything". The reason: the first click on an export with no limit would copy every installation and every colleague off this machine. The customer-facing export does not need a window. Its scope is already one installation.

The exports have three more properties. Each one has a reason:

This section describes the Security screen.

The Security screen, under the People tab (global_admin only), also shows these events:

This screen is designed to show some things that this deployment does not record yet. An example is the source address a request came from. In that case the screen says so explicitly. It does not report that nothing happened. "Nothing has been collected yet" and "nothing happened" are different facts. This screen keeps them apart.

This section describes Your month, one operator’s personal summary.

Your month needs the role user or higher. It is one operator’s own record. It is counted from the same journal at the moment you open it. There is no separate counter for it either. You can reach it in three ways:

It never appears by itself for a month with nothing in it. Imagine a card that says "you deployed 0 installations" to someone who was on leave. It reads as a reprimand, not as information. If you open it yourself, it still answers. It says "nothing to summarise" for that month. A person who asked deserves an answer.

The headline figure is not deploys. It counts failures you fixed yourself. That means a run of yours failed on an installation. Then, in the same month, a run of yours on that installation succeeded. A clean deploy with no failure before it adds nothing. So deploying more to customers' production cannot raise this figure.

Each of the other figures states what it counts, because the plain words are ambiguous:

The window is one calendar month in UTC. So a run late on the last day of a month may count in the next month. The "where to look next" signals use a longer window, a quarter. The reason: two events in one month are a coincidence as often as a pattern.

Refusals are counted separately. A refusal is something the tool declined, where nothing reached a customer’s server. Refusals never count toward those signals. They measure the tool, not the work.

What it shows:

A gap is a place worth a second look. Each gap is written as where to look next. It ends with what to do about it. It is never written as "what you don’t know". On purpose, there is no comparison between people, no ranking, no streak, no target, and no export. The server sends one person’s own figures. Nothing here is built to hold a second person’s figures. Every gap line ends with something to do, and it names a real training module. A gap with no next step would be a judgement, not a metric. And no signal ever counts questions asked. A metric on questions teaches operators not to ask.

A support_admin and higher also see a team view of the same gaps. It shows failure classes across the team. It has no figure per person at all. Lower ranks do not get this block. The block is also hidden when the team has no gaps. There is no export of the month or the gaps. Adding one would be a real decision, not a small convenience. A gaps export next to the audit file would turn a "where to look" list into a personnel file.