Documentation · Connectors & alerting
Connectors & alerting
ForgeOrbis brings logs in, identity through, and issues out to the people and tools that resolve them. The moment Orbis detects a problem, it routes the cited finding to the responsible owner, opens a ticket, and keeps the channel updated, without anyone watching a dashboard.
Overview
Connectors fall into four groups. Log sources and identity stay entirely inside your perimeter. Alerting connectors send issues outward, and export connectors forward the audit trail to your SIEM. Alerting is the only path where anything leaves your network, and it does so only where you allow it, carrying the finding and a link to the evidence, never raw log lines.
The alerting flow
Every alert follows the same five steps, from detection to a closed ticket:
- 01
Detect
Orbis spots the issue in your logs and grounds it in cited evidence: the file, the line, the match.
- 02
Route
Severity and the responsible owner come from your ownership map, so the right manager is chosen, not everyone.
- 03
Notify
The owner hears it in Slack, Teams, or email, and on-call is paged for a SEV-1.
- 04
Ticket
A Jira, ServiceNow, or Asana ticket opens automatically with the finding and a link to the evidence.
- 05
Update
Orbis posts updates to the channel and closes the ticket when the condition clears.
Ownership routing
The point of routing is to reach the responsible person, not everyone. You define an ownership map that ties a log source, process, or site to the team and manager who owns it, together with the channel to post in, the ticket project to file under, and the escalation policy to page. When Orbis detects an issue, it looks up the owner for the affected process and severity and routes accordingly.
Example ownership rule
Matches
process = printservice · site = STATION_A1
Owner
Priya Nair · MES Print Reliability
Notify
Slack #mes-incidents, page on SEV-1
Ticket
Jira MESOPS · Incident
Ownership and scope come from the same directory that backs roles (Entra, Okta, or LDAP), so the person paged at 2 a.m. is always someone with authority over that process, and never someone outside their folder scope.
Notify
Reach the owner where they already work. Real-time for SEV-1 and SEV-2; a rollup digest for the rest. Updates land in the same thread as the situation changes and recovers.
Slack
outboundNotify a channel or the on-call owner when Orbis detects an issue.
Microsoft Teams
outboundSend issue alerts and status updates to a Teams channel.
Email (SMTP relay)
on-premEmail the responsible manager through your own mail relay.
PagerDuty
outboundPage the on-call owner for SEV-1 issues via an escalation policy.
Tickets & ITSM
A ticket opens automatically with the finding, its severity, and a link to the evidence. Orbis keeps the work notes current and transitions the item to Done when the condition clears, so the tool of record always matches reality.
Jira
outboundOpen and update a Jira ticket for each detected issue.
ServiceNow
outboundRaise an ITSM incident in ServiceNow with the right assignment group.
Asana
outboundCreate a task for the owning team when an issue is detected.
Document
Turn a cited finding into an incident write-up or update a runbook, so the post-incident record links straight back to the log lines that prove it.
Confluence
outboundPublish incident write-ups and runbooks from cited findings.
Severity mapping
Orbis assigns a severity to each finding and maps it to the priority fields your tools already use, so nothing needs re-triage:
| Severity | Meaning | Notify | Jira priority | ServiceNow |
|---|---|---|---|---|
| SEV-1 | Production stopped or data at risk | Page on-call + channel | Highest | 1 - Critical |
| SEV-2 | Degraded, recovering, or repeating | Channel + owner DM | High | 2 - High |
| SEV-3 | Noticed, not urgent | Digest / ticket only | Medium | 3 - Moderate |
Governance & security
Alerting is the one place data can leave your perimeter, so it is the most tightly governed:
- Outbound only. Alerting connectors send; they never open an inbound path back into ForgeOrbis.
- Opt-in and allow-listed. Nothing is sent until you enable a connector, and only to destinations on the egress allow-list. Everything else is denied by default.
- Minimal payload. The default payload is the finding plus a link back to the cited evidence. Raw log lines stay inside; you choose per connector whether even a short excerpt may travel.
- Vault credentials. Webhook URLs, tokens, and API keys resolve from your secret vault at send time and are never stored in ForgeOrbis.
- Audited. Every dispatch, to whom, at what severity, with which citation, is written to the tamper-evident audit log and can be forwarded to your SIEM.
Air-gapped deployments
An air-gapped site keeps the same flow but points every connector at on-prem targets: Mattermost instead of Slack, Jira Data Center and Confluence Data Center instead of their cloud counterparts, and an internal SMTP relay for email. Where a target must live outside the network, alerts can be pushed through a one-way export so nothing can reach back in.
Setting it up
Add and configure connectors from the Connectors screen. Each one lists exactly what leaves your network and reads its credentials from your vault. Map your processes to owners once, choose the channels and projects per team, and Orbis handles the rest, from the first detection to the closed ticket.