Skip to content

Operational Monitoring and Incident Response

The fourth question in a serious review usually follows the other three: when something breaks, how do you find out, and what do you do about it? This page answers it for the systems Endeavor Engineering runs, and says where the answer stops.

What this covers

Our own engineering and delivery systems: the pipelines that build, test and release the software we ship you, the tools our engineers use to do it, and the scheduled checks that watch them. That is where a failure would first put a release, a fix or a piece of evidence at risk.

Two things it does not cover, and why:

  • A connector running in your environment. It runs on your Seeq agent, inside your network, under your monitoring and your controls. Its own health reporting appears in Seeq, as described on Connectors ++.
  • A multi-tenant VirtualForge production cloud. It is not serving production tenants yet. The same monitoring is designed to extend to it, and that is described as design, not as something running (Operational events and notifications).

How we find out

  • Everything reports to one place. Every build, test run and release on our main branches, and every scheduled check, sends its outcome to a single notification service. One service means one set of rules for what matters, applied the same way everywhere. The service is built on the Notification SDK.
  • Every event is recorded. Successes as well as failures go into a central log kept for 400 days, long enough to cover a full annual audit period with margin.
  • Silence is reported too. Most monitoring fails quietly: the job that never ran raises no error. A daily watchdog checks for exactly that, such as a scheduled run that did not happen, a workflow that was switched off, or a released version without its test evidence, and reports each one. The watchdog is itself watched: if a day passes without it reporting, an alert is raised on its behalf.

What happens next

  1. A failure that matters raises an alert with a named responder in Jira Service Management, prioritized by what failed. A failed release is high priority. Repeated failures of the same thing count on one alert rather than flooding the queue, and the alert closes itself when the next run succeeds.
  2. A serious alert opens an incident automatically, linked to the alert, in an internal operations space. A responder can also open one from a lower-priority alert when it warrants it. The incident is where the event, its fix and its review are recorded together.
  3. A person resolves the incident, once the service is actually recovered. Automation notes what it sees (the failure recurring, the next success) but never declares an incident over.
  4. Serious incidents are reviewed. A resolved high-priority or major incident gets a post-incident review: what happened, why, and what changes. It is approved and published, and is due within ten business days.

If it affects you

Engineering incidents are kept internal: they are never visible on the customer support portal. If one affects you, it is linked to your support request, and you hear about it on that request, from a person, under the same commitment as any other request (Getting Support). You do not have to watch a status page to find out whether something on our side is the cause.

Where it stands honestly
Live All of the above, for our engineering and delivery systems, since October 2026. Each stage was tested end to end before it was relied on
Responder coverage We are a small, senior team. Alerts reach a responder in business hours; we do not run a 24×7 on-call rotation as standard. If you need defined coverage, we agree it during contracting
Infrastructure Our internal infrastructure monitoring is being connected to the same service; until it is, it is monitored separately
The record The central log is an operational record. Whether it is also archived to write-once storage, so it can serve directly as audit evidence, is an open decision in our compliance program
Platform components The incident capability uses a vendor interface that is still in beta. It is isolated behind one component, and a failure there never loses the alert

None of this is a certification. Where it fits in our SOC 2 program, and what is in audit scope, is Compliance posture.

Asking

If your review needs more than this page, for example how a specific kind of failure would be handled, or the record of a past incident that affected you, ask us through the Endeavor Engineering resources hub or your usual Endeavor Engineering contact.