Sentinel: knowing what changed without adding a dependency

Developers depend on a lot of moving parts. A framework ships a release with a breaking change in the changelog. An API starts returning HTTP 404 where it used to return HTTP 200. A version field that used to say 1.4.2 now says 1.5.0. A dependency publishes to PyPI while you are asleep.

Checking all of that manually is tedious, forgettable, and exactly the kind of work that should be a script. But most monitoring tools ask for an account, an agent, a config file, and a dashboard. I wanted something smaller: a single command that prints what changed and gets out of the way.

So I built Sentinel with one hard constraint — zero third-party dependencies. Python 3.11+ and the standard library. pip install . and go. It runs anywhere Python runs, including CI images you do not control.

The design principle: monitoring and updating are different things

This is the decision I am most confident about.

Monitoring is passive. It reads public information, stores observations, and reports diffs. It can never destroy anything.

Updating is explicit and potentially destructive. It downloads artifacts and replaces software. It can absolutely break your day.

Sentinel keeps these capabilities in separate commands with separate mental models. sentinel check will never modify the software it watches. sentinel upgrade will never run implicitly. When it does run, it verifies checksums before touching anything, installs into a versioned folder (<install-path>/<version>/) instead of overwriting in place, and is dry-run safe by default.

Most tools blur this line because it feels seamless. I think that seam is a feature: it is the moment a human should be paying attention.

What it watches

sentinel add github microsoft/vscode --monitor release
sentinel add github python/cpython --monitor commits
sentinel add http https://example.com
sentinel add api https://api.github.com/repos/microsoft/vscode --jpath '$.stargazers_count'
sentinel add pypi requests
sentinel add npm typescript --name "TypeScript"

GitHub releases, tags, and commits. Websites. JSON endpoints (drill in with $.version or any jpath). PyPI packages. npm packages. Custom headers with environment-variable secrets for authenticated endpoints.

The core of the product is the output, and the output is a diff, not an alert:

⚠ VS Code
  1.102.0 → 1.103.0
  New release detected

✗ example.com
  HTTP 200 → HTTP 404

⚠ My Product
  $.version:
  1.4.2 → 1.5.0

"Something changed" is noise. "The version went from 1.4.2 to 1.5.0" is information.

History is the feature

Every observation goes into SQLite. That turns a checker into a system:

• sentinel history VS Code — a timeline of every value a source has reported.
• sentinel uptime — uptime statistics computed from the checks log over the last 30 days.
• sentinel show VS Code — full detail: config, raw preview, recent changes.

This is where "I should check that" becomes durable. Three weeks later, when something breaks, the question is not "did it change?" but "when?" — and Sentinel already knows.

Built for scripts

CLIs that only work interactively are half a tool. Sentinel is designed for cron jobs, CI pipelines, and shell scripts:

sentinel check --json        # machine-readable output
sentinel check --exit-zero   # always exit 0
sentinel watch --interval 10m

Exit codes carry meaning: 0 = no changes, 1 = changes detected, 2 = one or more sources failed. That means you can drop it into a pipeline and branch on the result without parsing text.

What building it taught me about CLI design

• Interactive by default, non-interactive when piped. sentinel add opens a friendly picker. sentinel add github owner/repo --monitor release does the whole thing in one line. Both matter.
• Resolve names like humans do. sentinel check VS Code matches by id, name, or unique name prefix. Making users paste IDs breaks the flow.
• Print nothing when nothing changed. Silence is the success state. A monitor that begs for attention every hour gets muted, and then it is useless.
• Verify before you trust. Sentinel checks that a GitHub repository exists when you add it, unless you pass --skip-verify. Typos should fail at setup time, not three weeks later in a cron log.

Why zero dependencies

It is partly ideology and partly pragmatism. Every dependency is a supply-chain surface, a version-drift problem, and a reason the tool won't install on an old base image. The standard library has HTTP clients, JSON parsing, SQLite, hashing, and terminal formatting. For this problem, that is enough.

The result is a tool that installs in seconds with no resolver gymnastics and works in the most restricted environments I can find. For a utility whose job is reliability, that is the correct trade.

Sentinel is MIT-licensed and open source. Add one source — the dependency you worry about most — and see whether knowing sooner changes how you work.

→ github.com/Pranesh-Selvaraj/Sentinel