Every monitoring tool I've used makes me leave my terminal to click through a web dashboard.
I spend my day in VS Code and deploy with git push, but to add a health check I need to open a browser, log in, click "New Monitor," fill out a form, and click save. Then do it again for the next endpoint. Configuration lives in someone else's database, not my repo.
This felt wrong.
Most monitoring tools are dashboard-first. The workflow looks like:
The result:
git diff for dashboard clicks.Tools like UptimeRobot and BetterStack are excellent at what they do. But if your deployment workflow is git push → CI → production, having monitoring configured through a web form is the odd one out.
I wanted monitoring that fits the way I already work:
# monitors.yaml — checked into the repo
version: 1
monitors:
- name: production-api
url: api.example.com/health
interval: 60
expect:
status: 200
contains: "ok"
alerts:
slack: "#oncall"
- name: website
url: example.com
interval: 60
expect:
status: 200
Deploy it the same way I deploy everything else:
# .github/workflows/deploy-monitors.yml
name: Deploy Monitors
on:
push:
paths: [monitors.yaml]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: curl -fsSL termwatch.dev/install.sh | sh
- run: termwatch validate
- run: termwatch deploy
env:
TERMWATCH_API_KEY: ${{ secrets.TERMWATCH_API_KEY }}
Check status without opening a browser:
$ termwatch status
NAME STATUS RESP CHECKED
api-health ✓ UP 124ms 32s ago
web-app ✓ UP 89ms 32s ago
payment-svc ✗ DOWN - 1m ago
postgres ✓ UP 12ms 32s ago
Monitor changes show up in pull request diffs. The configuration is version-controlled. The deployment is automated. Everything is a text file or a terminal command.
The core idea is simple: monitors are code. They live in your repo, they're reviewed in PRs, and they're deployed through CI.
This gives you some things that dashboard-configured monitoring can't:
1. Review before deploy. Someone changes interval: 30 to interval: 300? That shows up in a diff. A teammate will ask why.
2. Rollback is git revert. Accidentally deleted a monitor? git revert brings it back. Your monitoring config has the same guarantees as your application code.
3. Environment parity. If you have monitors-staging.yaml and monitors-production.yaml, you can keep them in sync with the same tooling you use for application config.
4. Onboarding. New team member looks at monitors.yaml and immediately understands what's being monitored, at what interval, and what alerts exist. No dashboard walkthrough needed.
This approach is not for everyone, and there are real downsides:
No visual dashboards. If your team prefers charts and graphs over terminal tables, tools like BetterStack or Grafana are a better fit. A web dashboard exists for viewing results, but configuration is CLI-only.
Learning a schema. You need to learn the YAML format. It's simple, but it is one more thing to learn.
Single check region. Tools like UptimeRobot check from multiple geographic locations to reduce false positives. Single-region checks are more prone to network-level false alarms.
Fewer integrations. Established tools have 50+ notification channels. Starting with Slack, Discord, and email covers most cases but not everyone.
Newer and less proven. A tool with tens of thousands of users has battle-testing that a new tool simply hasn't had yet.
For developers who already live in the terminal and manage infrastructure with code, the tradeoffs are worth it. For teams that prefer GUIs or need enterprise features, UptimeRobot and BetterStack are great products.
I built TermWatch to scratch this itch. It's a CLI that reads monitors.yaml, deploys monitor configuration to a hosted checking service, and sends alerts when things go down.
It's available via dotnet tool install -g termwatch (NuGet) or as standalone binaries with SHA256 checksum verification.
The free tier gives you 5 monitors with 5-minute check intervals — enough to monitor a real side project stack.
If you've solved the "monitoring from the terminal" problem differently, I'd genuinely like to hear how. Do you use Prometheus + Alertmanager? Checkly? A custom script? What works and what doesn't?
Drop a comment or find me on GitHub — I'm still figuring out the right balance between simplicity and features, and real-world feedback is the most valuable thing right now.
No responses yet.