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.
If you have not installed it yet, do installing 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.
These are the first things anyone asks when something breaks. Write them down now.
Keep them with this exercise, not in a scratch note. Having these three lines ready saves one round trip when you ask for help.
Start it and connect from the browser, as in first run and connecting.
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.
This step is the point of the exercise. Open the log while nothing is wrong.
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.
Type a command that does not exist and see how an error appears in the log.
HyperTeams□ Does the error line look visibly different from normal lines?□ Does it carry a timestamp?Do check the third. Confirming once what persists and what does not saves you the later "where did that go?"
Look at the three ways to run it and choose one now.
| Way | Right for me |
|---|---|
| From the terminal, only when needed | □ |
| Left running in the background | □ |
| Automatically when the machine starts | □ |
Do not skip the third line. If you plan to use schedules, auto-start is effectively mandatory.
1. Why read the log while nothing is wrong?
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.
2. Why locate the connection indicator in advance?
Half of "it isn't working" is actually "it isn't connected." Knowing where to check eliminates half the causes immediately.
3. How should you choose if you plan to use schedules?
Auto-start. A running machine is not enough — if the program is not up, the schedule does not fire.
Now register a folder to work in → Registering a working directory
□ 30 minutes□ A finished installation□ One terminal window□ hyperteams --version ->□ node --version ->□ OS and version ->□ Does the terminal print an address?□ Does that address open a screen?□ Is there a "connected" indicator somewhere on that screen?□ 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□ You shut it down cleanly□ You saw what the screen does when it is down□ You checked what survives a restartHow 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)□ 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