See the
whole watch. Know what
changed.
Monitoring, syslog and detections for every client you look after, on one screen, with the last hour in plain view.
Sign in- Critical
- 0
- High
- 1
- Acknowledged
- 0
Illustrative
One watch across every client.
Each client, gateway and service is one row. Twelve five-minute bins show the worst state in each, so the last hour reads left to right without opening anything. Open a row to drill in, and the rest of the rack stays where you left it.
- A hollow bin means the data is missing
- It never counts as healthy. Gaps stay on the screen, even when they make it less tidy.
- Shape, colour and a word
- Every severity has its own symbol and its name beside it, so nothing depends on telling two colours apart.
- The screen holds still
- Rows stay in order while you work an incident. Data changes inside the layout, and the layout does not move.
Detections that bring their evidence.
Log events are checked against your rules. An alert opens with the rule that fired, the events that matched and the client affected. Each alert keeps the query that produced it, so you can replay the events or capture them into an incident before they age out.
Repeated failed sign-ins, then a success
- Severity
- High
- Rule type
- Sequence
- Evidence
- 41 failed sign-ins and 1 success from one address in 6 minutes
- Scope
- One client, one account
Each client gets its own plain view.
Give a client a sign-in and they see their services, incidents and service levels in plain language, under your name and accent colour. They see only their own data. Your team keeps the detail.
What your team sees
What your client sees
Service affectedYour internet connection at the head office is down.
We saw it stop responding and we are working on it. You do not need to do anything.
A region is only healthy once it has been probed.
Each ingest region shows whether it was deployed, when it last passed a probe and how long ago that was. OverWatcher does not fail its database over between regions.
- Configured
- Set up for your account. This says nothing about whether it works.
- Probed
- A check ran against it. The time and source are recorded.
- Healthy
- The latest probe passed and is recent.
- Degraded
- It answers, but slowly or only in part.
- Unreachable
- The latest probe could not reach it.
- Not verified
- No probe has run. It is never drawn as healthy.
Every change leaves a record.
Sign-ins, rule edits and changes to clients are written to an append-only chain with who did it, what they touched and when. The database hashes each entry into the chain.
| Time (UTC) | Who | Action | What it touched |
|---|---|---|---|
| 10:42:07 | analyst@example.com | alert.acknowledge | Head office firewall |
| 10:39:51 | admin@example.com | rule.update | Repeated failed sign-ins |
| 10:31:18 | admin@example.com | site.create | Warehouse |
| 10:30:02 | analyst@example.com | auth.login_mfa | analyst@example.com |
What's built today
Working now
- Syslog over TLS with a client certificate per source, and HTTPS log ingest with a token
- Metrics from an OpenTelemetry agent, with an install config for each asset
- Service checks over HTTP, TCP, ICMP, DNS and TLS
- Threshold, sequence, absence and Sigma detection rules, with dry runs and versions
- Alerts, incidents with evidence export, and escalation over email, Teams, Slack, webhook and SMS
- Client portals with their own sign-in, service levels and downloadable reports
- OIDC single sign-on, two-factor sign-in, and client scoping enforced in the database
- An append-only audit record, legal hold, and client deletion that needs a second administrator
- Three regions that each run the full stack and replicate to each other, with one writable database leader at a time
Not built, and not claimed
- SNMP polling and automatic device discovery
- Connectors for cloud providers
- A confidence score on detection rules