Skip to content

Operational Events and Notifications

Connected intelligence depends on knowing what your systems are doing. Every historian, connector, pipeline and scheduled job produces outcomes: it ran, it failed, it is late, it recovered. In most operations those outcomes land in a dozen places in a dozen formats, and the one that matters is noticed late, if at all.

VirtualForge's notification engine brings them into one stream. Every source reports the same way, one set of rules decides what each outcome deserves, and adapters deliver it to the tools people already work in.

How it works

Stage What happens
One event shape Every source sends the same small, validated record: what it is about, its status (success, failure, warning, information), its severity, a summary, and a link. A new source learns one contract, not one per destination
One set of routing rules Rules decide, by source, status and severity, whether an event is recorded only, posted for people to see, raised as an alert for a responder, or opened as an incident for review. The rules live in one place, so behavior is consistent and testable
A record of everything Every event is written to a durable log, whatever else happens to it, so there is always a queryable account of what ran and how it ended
Adapters to your tools Delivery to a chat platform, an alerting service or an incident system is an adapter. Supporting another platform means adding an adapter, not changing the engine
Silence is an event too A scheduled source that stops reporting is detected and raised, so a job that quietly never ran does not look the same as one that succeeded

Three behaviors matter in practice:

  • One alert per problem. A failure that keeps recurring counts on one open alert, and the alert closes when the next run succeeds, so a responder sees the state of a problem rather than a pile of messages.
  • Nothing lost on the way. Outputs are ordered so that a failure in one (a chat outage, say) never stops the record or the alert, and a retried event is recognized, so it never opens a second alert or incident.
  • People decide when it is over. For incidents, the engine notes what it observes, but a person resolves the incident and its review follows.

Where it stands

Using our four status terms:

Capability Status
The engine (event contract, routing, the record, adapters for chat, alerting and incident management) Running in production for Endeavor Engineering's own operations since October 2026: every build, test and release, scheduled checks, alerts and reviewed incidents. How we use it is on Operational monitoring and incident response
As a VirtualForge platform capability for your systems and your tools In active development. The engine was built platform-neutral from the start, so it can run in a VirtualForge deployment with that deployment's own adapters; that deployment is not available yet
Proactive connector health monitoring, raising issues from connector diagnostics Planned, as part of Connectors ++; it is designed to use this engine
Notifications inside Seeq, through the VirtualForge Toolbox messaging point The Toolbox is in rebuild; delivering these events to it is planned

The adapters in use today are for Slack, Jira Service Management (alerts, heartbeats and incidents), and AWS (the record and the engine's state). They are examples of the pattern, not a limit on it. The engine's core is the Notification SDK.

Why it is built this way

  • Industrial operations already have tools. A platform that insists on its own console for alerts adds a place to look. Adapters let events arrive where your team already works.
  • Consistency is a control. When every source is routed by the same rules, what is alerted, what is recorded and for how long can be stated once and checked, which is what an auditor asks for.
  • It is proven on us first. We run our own engineering on it before offering it to anyone else, so its behavior under real failures is known rather than predicted.