System Health Monitor
One incident, one page, clear summary.
System Health Monitor
IT & Data Operations
- RuleDone:
An alert arrives from your monitoring tool or our uptime checks.
- RuleDone:
Rules group it with related alerts into one incident.
- RuleDone:
Rules set severity and page on-call within seconds.
- AIWaiting for approval:Waiting for you
A ticket opens; AI adds a summary with graph links.
- RuleNot started:
If nobody acknowledges, it escalates to the next person, then a backup contact.
- RuleNot started:
When things recover, the incident closes and a review draft is saved.
For example: At 2 a.m.
Waiting for you. Nothing has changed yet.
Standard. Low-risk, reversible changes. Every action is logged.
What is System Health Monitor?
In shortSystem Health Monitor is an AI automation for IT & Data Operations teams that works with Freshservice, GitHub Issues, Instatus, Jira, Microsoft Teams and 8 more apps. Groups related monitoring alerts into one incident, pages on-call fast, opens a ticket and adds a plain-English summary with links to real graphs. It is built for on-call engineers, small SaaS or e-commerce tech teams and managed service providers.
Last reviewed
Key facts
- Department
- IT & Data Operations
- Starts when
- A monitoring tool raises or clears an alert, or one of our uptime checks fails
- Works with
- Freshservice, GitHub Issues, Instatus, Jira, Microsoft Teams, OCI Monitoring, Opsgenie, PagerDuty, Prometheus, Slack, Statuspage, Twilio, Uptime Kuma
- Run modes offered
- Shadow, Draft, Assisted and Auto
- Human control
- Standard
- Status
- Available now
The problem today
One outage sends 30 alerts from different tools, so people mute channels and real problems are missed at night. Writing the incident note and status update takes time when everyone is stressed.
What it does
It sits after your existing monitoring tools. Rules group related alerts into one incident, set severity and page the right on-call person. A ticket is opened, and AI adds a short summary with links to the real graphs; paging never waits for the AI. Public status page updates use templates and are always approved by a person.
How does System Health Monitor work?
How it works- Rule you set
- AI step
- A person decides
- Step 1Rule
An alert arrives from your monitoring tool or our uptime checks.
- Step 2Rule
Rules group it with related alerts into one incident.
- Step 3Rule
Rules set severity and page on-call within seconds.
- Step 4AI
A ticket opens; AI adds a summary with graph links.
- Step 5Rule
If nobody acknowledges, it escalates to the next person, then a backup contact.
- Step 6Rule
When things recover, the incident closes and a review draft is saved.
What you get
Key features- Alert grouping by service and dependencies
- Paging via PagerDuty, Opsgenie, or Slack plus SMS
- Escalation on no acknowledgement (5 min SEV1, 15 min SEV2)
- Low-urgency alerts wait until morning during quiet hours
- Templated public status updates (Statuspage or Instatus)
- Post-incident review draft with a timeline from the event log
How much does it do on its own?
Run modesPick a mode to see what System Health Monitor would do at each step.
Every automation starts in Shadow. Move it up when you are ready, and back down at any time. How run modes work
System Health Monitor in Shadow
Runs on real data and shows what it would have done. No app is changed and no message is sent.
- Rule
An alert arrives from your monitoring tool or our uptime checks.
Watches for it
- Rule
Rules group it with related alerts into one incident.
Runs on real data, read only
- Rule
Rules set severity and page on-call within seconds.
Runs on real data, read only
- AI
A ticket opens; AI adds a summary with graph links.
Shown to you as a suggestion
- Rule
If nobody acknowledges, it escalates to the next person, then a backup contact.
Shown to you as a suggestion
- Rule
When things recover, the incident closes and a review draft is saved.
Shown to you as a suggestion
Shadow vs Auto for System Health Monitor
Auto is the most it can do on its own. Here is each step side by side.
| Step | Shadow | Auto |
|---|---|---|
| In short | Runs on real data and shows what it would have done. No app is changed and no message is sent. | Runs without approval, with limits, alerts and a kill switch. Unlocks after a trial period in Assisted. |
| Step 1An alert arrives from your monitoring tool or our uptime checks. | Watches for it | Runs on its own within your limits |
| Step 2Rules group it with related alerts into one incident. | Runs on real data, read only | Runs on its own within your limits |
| Step 3Rules set severity and page on-call within seconds. | Runs on real data, read only | Runs on its own within your limits |
| Step 4A ticket opens; AI adds a summary with graph links. | Shown to you as a suggestion | Runs on its own within your limits |
| Step 5If nobody acknowledges, it escalates to the next person, then a backup contact. | Shown to you as a suggestion | Runs on its own within your limits |
| Step 6When things recover, the incident closes and a review draft is saved. | Shown to you as a suggestion | Runs on its own within your limits |
| True in every mode | Rules, not AI, decide severity, paging, escalation and closing. | |
What it will never do on its own
Safety & human control- Rules, not AI, decide severity, paging, escalation and closing.
- AI never claims a root cause or says "resolved", and every summary links to graphs.
- Public status updates are approved by a person in every mode.
- Your existing alerting stays on until shadow shows zero missed critical alerts.
- Secrets and personal data in logs are scrubbed first; a separate dead-man check watches the monitor itself.
- You approve before it acts
- Your data stays yours
- It knows its limits
- Stop anytime
What will you see on your dashboard?
Results you can trackTargets are quality goals the automation is built to reach. Estimates are calculated from your own volumes.
- Tracked
Time to acknowledge, time to resolve, alert noise ratio, incidents by service, repeat incidents
Measured on your own data
- Target
Alert noise down ≥ 50% (target)
A goal it is built to reach
- Target
Time to acknowledge critical under 10 minutes (target)
A goal it is built to reach
- Target
Critical alerts paged 100% (target)
A goal it is built to reach
- Target
Page sent within 60 s, p95 (target)
A goal it is built to reach
- Target
Grouping accuracy ≥ 90% (target)
A goal it is built to reach
- Target
Pages per incident ≤ 2 (target)
A goal it is built to reach
At 2 a.m. a shop's checkout API and database raise 18 alerts. The on-call engineer gets one SMS for one SEV1 incident, and a GitHub issue opens with a summary and links to the error-rate graph.
Who is System Health Monitor for?
- On-call engineers
- Small SaaS or e-commerce tech teams
- Managed service providers
Industries: SaaS & tech, E-commerce & retail, Professional services
Connects to the apps you already use
Works withApp names are trademarks of their owners. Charviam connects to them; it is not a partner or reseller.
- Freshservice(optional)
- GitHub Issues
- Instatus(optional)
- Jira(optional)
- Microsoft Teams
- OCI Monitoring
- Opsgenie(optional)
- PagerDuty(optional)
- Prometheus
- Slack
- Statuspage(optional)
- Twilio
- Uptime Kuma
What do you need to set it up?
Setup- Connect alert sources (Alertmanager, OCI Monitoring) and uptime targets
- Fill the service catalogue: service, tier, owner, dependencies, runbook
- Choose pager, on-call levels, backup contact and timeouts
- Choose ticket tool and (optional) status page
- Set quiet hours for low-urgency alerts
Typical setup
- 01Connect your apps
- 02Configure the rules
- 03Run a watch-only trial
- 04Go live
Not included
- Replacing your monitoring tools
- Auto-fixes (restart, rollback, scale)
- Root-cause claims
Questions about System Health Monitor
FAQSee System Health Monitor on your own data
WalkthroughIt starts in Shadow, where it only watches and suggests, so nothing changes in your apps until you say so.