import { Screenshot } from '@site/src/components/media/Screenshot';

# Do the weekly check

This lesson is one habit. It takes fifteen seconds, and it is the difference between adjusting course
on a Tuesday and explaining a bill in arrears.

Open your [organization](/glossary/organization). You land on the [dashboard](/glossary/dashboard).

<Screenshot
  src="img/screenshots/dashboard-usage.png"
  capture="An organization dashboard showing the workspaces panel and the plan/usage panel together. Usage against plan limits should be legible, since that is the number this lesson tells people to check weekly. Redact org name and any customer-identifying detail."
  caption="Usage against plan limits is the panel worth a weekly glance."
/>

## Answer four questions

Do this now, on your own dashboard. Each answer is somewhere on the page.

**1. How much of this billing period's compute have you used?**

Find the plan and usage panel. Note the figure and the period it covers.

**2. Is that ahead of or behind where the calendar is?**

Two-thirds through the month with 90% of the budget spent is a finding. Two-thirds through with 40%
spent is not. The absolute number tells you nothing without that comparison, which is why the habit
is *weekly* rather than a glance whenever someone worries.

**3. How many workspaces are there, and is every one of them in use?**

An abandoned [workspace](/glossary/workspace) still holds storage. If you cannot name who uses one, that is worth chasing.

**4. Is anything mid-provision right now?**

A workspace still deploying is not usable. Sending someone to it produces a confusing bug report
rather than an error message.

## Now check the thing the dashboard does not volunteer

Are start times slow?

If sessions or [clusters](/glossary/cluster) take a long time to become available while usage looks healthy, you are
probably hitting a **concurrency** limit rather than a capacity one:

| | What it bounds | How it fails |
| --- | --- | --- |
| **Capacity** | total compute this period | work refused, or a larger bill |
| **Concurrency** | how much runs at once | work *accepted* but queued |

The second gets misdiagnosed constantly, because it does not look like a limit. It looks like the
platform being slow, and gets reported that way.

If you have heard "Eugo feels sluggish this week" from anyone, check concurrency before you believe
it.

## Set the habit up so you do not rely on remembering

Put a fifteen-second recurring reminder on a day you are already at your desk. Answering four
questions weekly costs you a minute a month.

The alternative is not "check it when it matters." It is finding out afterward.

## Before you optimize anything

The dashboard tells you *how much*. It does not tell you *which workloads*, and that is what makes the
number actionable.

Tuning a job responsible for 3% of the bill is effort with nothing to show for it. Establish which
workloads dominate first, then look at those. The
[cost optimization checklist](/resources/cost-optimization-checklist) is the working form of that
order.

## If a team is always at a limit

The plan does not fit how they work.

That is a sizing decision, not a discipline problem. Treated as the latter, you get people running
smaller jobs than they should, or waiting on capacity, which costs more in salary than the upgrade
would.

## What you now know

- The four questions, and that question 2 is the one that makes the others mean anything.
- That "the platform is slow" is often a concurrency limit wearing a disguise.
- Why attribution comes before optimization.

Next: [inviting members and assigning roles](./03-members-and-roles.mdx). Getting people into a
workspace with the right access, in the right order.

---

**Video:** [Reading the dashboard](/videos/reading-the-dashboard) (same material, with a transcript).

---

Source: https://university.eugo.io/lesson/workspaces-and-organizations/the-dashboard