# Use the log to answer a real question

The [activity log](/glossary/activity-log) is usually described as a governance feature. In practice you will reach for it as a
**diagnostic tool**, when something changed and nobody remembers changing it.

Open your [organization](/glossary/organization)'s activity log and work through these three.

## 1. What changed most recently?

Read the newest few entries. You are looking for the shape of what gets recorded: [workspaces](/glossary/workspace) created
or removed, roles changed, clusters launched and stopped, plan changes.

Note who appears and how recent the entries are. A quiet log is itself information: either nothing is
changing, or people are working in a different organization than you think.

## 2. Who launched the longest-running cluster this week?

Find a cluster launch entry, then look for its matching shutdown.

If you find launches without shutdowns, you have found where money goes. A cluster bills for as long
as it runs, whether or not it is doing anything. See
[plans, usage, and billing](./04-plans-and-billing.mdx).

Worth being careful how you use this. It is almost never carelessness: someone launched a cluster,
got their result, and did not know an [idle cluster](/glossary/idle-cluster) costs the same as a busy one. One conversation
fixes that permanently. Treating it as a discipline problem does not.

## 3. Has anyone's access changed since they joined?

Look for role-change entries. For each, ask whether the change is still appropriate.

Permissions accumulate. People join projects, move teams, cover for someone, and keep the access
nobody revisits. The log is the only place that history exists. A current role list tells you what
people have, not how they got it or whether it was meant to be temporary.

## The question it is actually best at

**"What changed just before this broke?"**

When a workspace stops behaving the way it did last week, that is the fastest route to an answer.
Failures are frequently preceded by a change, and the log is where you find which one. It turns a
vague report into a timeline.

Try it the next time someone tells you something used to work.

## Check access before you need it

One thing worth doing now rather than during an incident: confirm that the people accountable for the
environment can actually read the log.

Discovering that the person diagnosing a problem lacks access is a bad moment to discover it.

## What it will not tell you

**Not a profiler.** It records platform actions, not what happened inside your code. For a slow run,
see [watching a run](/lesson/eugoide-essentials/monitoring-a-run).

**Not version control.** It records that a workspace changed, not what your code used to say. Commit
your work.

## What you now know

- The three questions the log answers faster than asking around.
- That unmatched cluster launches are a cost signal, and how to raise it usefully.
- That "what changed just before this broke" is its highest-value use.

Retention and coverage specifics are in the
[administration guide](https://docs.eugo.io/docs/administration), which stays current as the platform
changes.

---

Source: https://university.eugo.io/lesson/workspaces-and-organizations/activity-logs