# Check your first connection

> **What you will learn**
> Not a chapter to read but one to **do**. Start it, connect, read the log, shut
> it down. The point is to build **the knowledge of where to look** before you
> need it.

## What you need

```
□ 30 minutes
□ A finished installation
□ One terminal window
```

If you have not installed it yet, do [installing](/guide/ht-install) first.

**You will not ask it to do any work yet.** This exercise is not about whether
work runs — it is about whether you can see the state.

---

## Step 1 — Write down three versions (5 min)

These are the first things anyone asks when something breaks. **Write them down
now.**

```
□ hyperteams --version   ->
□ node --version         ->
□ OS and version         ->
```

**Keep them with this exercise, not in a scratch note.** Having these three lines
ready saves one round trip when you ask for help.

---

## Step 2 — Start it and connect (5 min)

Start it and connect from the browser, as in [first run and
connecting](/guide/ht-first-run).

### What to look for

```
□ Does the terminal print an address?
□ Does that address open a screen?
□ Is there a "connected" indicator somewhere on that screen?
```

**Find the third one now.** Half of all "it isn't working" turns out to be "it
isn't connected." Knowing where that indicator lives removes half the cases.

---

## Step 3 — Go and find the log (10 min)

**This step is the point of the exercise.** Open the log while nothing is wrong.

```
□ You found where the log is written
□ You put the last few lines on screen
□ You saw what the lines look like when things are fine   <- this matters
```

**The third line is the reason.** If you have never seen a healthy log, you cannot
tell which line is the odd one when something breaks. They all look odd.

### Cause one error on purpose

Type a command that does not exist and see **how an error appears in the log.**

```
□ Does the error line look visibly different from normal lines?
□ Does it carry a timestamp?
```

---

## Step 4 — Shut down and restart (5 min)

```
□ You shut it down cleanly
□ You saw what the screen does when it is down
□ You checked what survives a restart
```

**Do check the third.** Confirming once what persists and what does not saves you
the later "where did that go?"

---

## Step 5 — Decide on auto-start (5 min)

Look at [the three ways to run it](/guide/ht-first-run) and **choose one now.**

| Way | Right for me |
|---|---|
| From the terminal, only when needed | □ |
| Left running in the background | □ |
| Automatically when the machine starts | □ |

```
How to choose:
  you use it once or twice a day     -> only when needed
  you use it throughout the day      -> background
  you are going to use schedules     -> auto-start (schedules do not run if it is down)
```

**Do not skip the third line.** If you plan to use schedules, auto-start is
effectively mandatory.

---

## Self-check

```
□ You wrote down the three versions
□ You know where the connection indicator is
□ You have seen a healthy log        <- if not, back to step 3
□ You have seen what an error line looks like
□ You picked a way to run it
```

---

## Check yourself

**1. Why read the log while nothing is wrong?**

<details>
<summary>Answer</summary>

**You need to know normal to spot the odd line.** A log you are seeing for the
first time looks suspicious from top to bottom.
</details>

**2. Why locate the connection indicator in advance?**

<details>
<summary>Answer</summary>

**Half of "it isn't working" is actually "it isn't connected."** Knowing where to
check eliminates half the causes immediately.
</details>

**3. How should you choose if you plan to use schedules?**

<details>
<summary>Answer</summary>

**Auto-start.** A running machine is not enough — if the program is not up, the
schedule does not fire.
</details>

---

Now register a folder to work in → [Registering a working directory](/guide/ht-working-directory)