Guides

Real setups, start to finish. Each one below combines a couple of Sentinel’s pieces — see Features for what each does on its own, or Automation for surface-by-surface reference.

Case study: a full local dev stack, one click to start

The problem: a frontend, an API, and a DB proxy, each in its own terminal tab. Closing a tab by accident kills the process; there’s no single place to see what’s actually running.

The setup:

1. Add three scripts in Sentinel, all in a Work folder: Web (npm run dev), API (cargo watch -x run), DB Proxy (cloud-sql-proxy ...), each with its working directory set.
2. Turn on auto-restart for DB Proxy — a proxy dropping and quietly not coming back is the kind of failure that wastes an afternoon.
3. Add a shell alias so the whole stack comes up in one command (see the CLI walkthrough):

   alias devup='sentinel start "Work/API" && sentinel start "Work/Web" && sentinel start "Work/DB Proxy"'
   

4. Run devup. All three show up in the menu bar with live status dots; open any of their log windows any time to check on them.

Result: one command in the morning, one place to check on all three, and a proxy that recovers itself if it drops.

Case study: a webhook tunnel you can trust

The problem: an ngrok/cloudflared tunnel for testing webhooks that silently dies mid-demo, and you don’t notice until the webhook call fails.

The setup:

1. Add the tunnel as a script, e.g. Tunnel (cloudflared tunnel run my-tunnel).
2. Leave auto-restart on (the default) — Sentinel restarts it automatically if it crashes.
3. Before a demo or a webhook test, use the Shortcuts status check walkthrough pattern: a shortcut that checks Get Script Status and only proceeds (opens the tunnel URL, kicks off the webhook test) if it’s actually up.
4. If it does crash and the rolling-window guard trips (three crashes in 30 seconds), you get a notification instead of silence — see Features → Reliability.

Result: no more discovering a dead tunnel from a failed webhook call ten minutes into a demo.

Case study: don’t ship without your dependencies up

The problem: a build or deploy script that assumes a local dependency (a proxy, a mock server) is running, and fails with a confusing error when it isn’t.

The setup:

1. Wrap the check in your build script using the CLI gate walkthrough:

   if ! sentinel status "Work/DB Proxy" > /dev/null; then
     sentinel start "Work/DB Proxy"
   fi
   npm run build
   

2. Or, if you want a hard failure instead of an auto-start, use the AppleScript gate walkthrough to raise a clear error before the build even starts.

Result: a missing dependency becomes a one-line, readable failure instead of a stack trace three layers down.

Case study: replacing a wall of terminal tabs

The problem: you’re the person with twelve terminal tabs open, half of them running something you’d forget about if you closed them.

The setup:

1. Move each long-running command into a Sentinel script — see How it works for the three-step version.
2. Group them into folders by project so the menu bar list stays navigable as it grows.
3. Turn on the footer stats (Settings → Footer) so you get a CPU/memory read at a glance without opening Activity Monitor.
4. Pin a Shortcuts restart action for the one script you restart most, so the terminal never needs to come back for that alone.

Result: zero terminal tabs dedicated to “just keep this running” — Sentinel’s menu bar is the one place you check.

Have a setup worth adding here? These guides grow as the app does — Guides isn’t the full feature or command reference; for that, see Features and Automation.