Proactive support
See related issues. Investigate the wider impact.
GenticFlow connects related endpoint signals into incidents so your team can see affected devices and recurring patterns. Investigate the scope and possible causes, then use the findings to guide the response.
Monitoring is part of the platform. Supported detection rules turn qualifying evidence into incidents; eligible investigations can then help your team understand possible causes and choose a response.
Matching application crashes on Finance laptops.
Application CrashMatching crash evidence is available on five endpoints. Review the crash details and recent changes before choosing a response; the shared symptom alone does not establish a root cause.
Connect endpoint monitoring to incident response.
Use incident context to understand related support issues and coordinate the next steps across affected endpoints.
One incident, one coordinated response across every affected endpoint.
Illustrative printer incident: related reports can point to a shared dependency. The example below shows why technicians need to review scope before treating each report separately.
- Several related printer reports
- Technicians repeat context gathering
- Separate investigations without shared context
- 1 investigated incident
- 1 investigation
- Affected endpoints available for review
- 1 coordinated response
How it works
From device signal to support-ready incident.
Review the observed condition, affected endpoints, and supporting evidence in one record. Investigation and follow-up are separate steps, subject to the incident type and your configuration.
Baseline
GenticFlow learns supported endpoint metric baselines over time. Observed values and event evidence help technicians distinguish normal variation from conditions that need attention.
Collect
Agents collect supported health metrics, event records, update state, and connectivity observations. Live diagnostics can add service and process detail when a technician investigates.
Detect
Supported detectors evaluate measurements and typed event evidence. Signal quality checks and incident-specific thresholds determine which observations qualify.
Correlate
Scheduled analysis evaluates related evidence against each incident type’s criteria. Live types can publish incidents; candidate types retain observations without creating incidents or triggering responses.
Investigate
After publication, eligible incidents can launch separate investigations to collect more evidence and explore possible causes. A finding may still contain open questions; investigation is not guaranteed for every incident.
Respond
Published incidents can feed configured tickets, notifications, and eligible workflows. Technicians review evidence and use supported playbooks or permitted actions, then verify the outcome.
Signal use cases
Signals GenticFlow can turn into support context.
Supported device signals provide context for monitoring and investigation. A signal alone does not prove a root cause or create an incident. Collection and detection vary by operating system and metric.
Application Crash
Collect supported application crash evidence to review recurring failures and investigate their impact.
Firewall Disabled
Flag endpoints whose firewall state moves outside expected policy so the team can investigate drift.
New User Account
Surface unexpected local account creation as a security-sensitive endpoint signal.
Security Event
Detect unusual authentication behavior and preserve the endpoint/user context for investigation.
Service Issue
Catch recurring service crashes or restart loops, such as spooler, VPN, update, or backup services.
Unusual Log Activity
Use Windows event logs to spot update failures, driver faults, service terminations, and app errors.
Unusual Network Activity
Detect DNS, gateway, connection, or reachability patterns that differ from the endpoint baseline.
Unusual Process Activity
Historical signal category. Automatic per-process anomaly detection is not currently active; technicians can inspect processes through live diagnostics.
Unusual Resource Usage
Detect CPU, memory, disk, uptime, or capacity drift against the learned baseline.
Incident use cases
Incident coverage and observation status.
Seven live incident types can publish when their evidence criteria are met. Candidate types are observations only, without incident responses. Historical types below describe retained records, not new incident detection.
Recurring Account Lockouts
Live: groups recurring account lockouts with observed accounts and timing. The cause remains unconfirmed until supported by investigation.
Application Crash
Live: correlates matching application crash evidence across enough endpoints and confirms it before publication.
Application Runtime Error
Candidate observation only: evaluates matching application runtime failures. Does not create incidents or trigger responses.
Likely Bad Update
Candidate observation only: evaluates application crashes associated with a version and known deployment. Does not create incidents or trigger responses.
Connectivity Outage
Live: groups at least five online endpoints losing shared connectivity targets within the same onset window.
Coordinated Administrator Creation
Live: flags the same administrator account created across at least five endpoints, with source-event and administrator-membership evidence.
Critical Disk Capacity
Candidate observation only: evaluates sustained critical pressure on a qualifying local volume. Does not create incidents or trigger responses.
Critical Endpoint Risk
Live: confirms multiple independent high or critical risk causes on an endpoint before publication.
Failed Login Burst
Live: groups qualifying failed sign-ins from the same public IP using Windows Security evidence.
Management Service Failures
Candidate observation only: groups verified management, security, or backup service failures. Does not create incidents or trigger responses.
Resource Pressure
Candidate observation only: evaluates sustained CPU, memory, or swap pressure. Does not create incidents or trigger responses.
Service Failures
Live: groups the same service failing across enough endpoints using source event evidence.
Endpoint Connectivity Outage
Retired detection: retained for historical records. Current connectivity incident detection evaluates shared failures across endpoints.
Widespread Application Instability
Historical record type. New application-crash incidents use the current evidence-based application crash detector.
Likely Bad Update
Historical record type. Current bad-update observations remain candidates and do not publish incidents.
Emerging Issue
Historical record type. New incidents require the criteria of a supported live type.
Endpoint Health Critical
Historical record type. Current critical endpoint risk detection requires independent qualifying causes.
Recurring Endpoint Issue
Historical record type, not a promise of automatic incident creation for every recurring issue.
Correlated Incident
Historical record type. Current correlation follows the criteria of each supported incident type.
Temporal Pattern
Historical or trend context, not an active incident publication type.
Predicted Threshold Breach
Historical trend type. New threshold-prediction incidents are not currently published.
Unusual Activity
Historical or trend context. Baseline deviation alone does not create an incident.
Baseline first
Normal is different in every environment.
A busy workstation, a print server, a backup endpoint, and a finance laptop should not share the same assumptions. GenticFlow treats normal as local to the environment so support teams can spot meaningful drift instead of chasing generic thresholds.
Incident output
A support-ready incident, not a pile of signals.
Published incidents retain their scope and detection evidence. An eligible investigation can add findings and proposed next steps. Available detail depends on the observations and checks completed.
Response paths
Detection is connected to resolution.
Incidents should not stop at diagnosis. GenticFlow connects the incident record to the resolution path that fits the risk and certainty of the case.
Known support issue
Route into a resolution playbook when the incident maps to a supported issue class.
Environment-specific response
Trigger an automation workflow when the fix needs organization, site, app, or policy-specific steps.
Fleet Investigation
Run full investigations on representative endpoints and check the validated signature across the fleet, automatically or with technician checkpoints, ending in one conclusion you can trace back to each endpoint. Technicians can also start one directly, scoped by organization, connector, group, or tag, with Quick and Complete depth options.
FAQ
Incident intelligence questions.
How device signals become incidents, what evidence they include, and when an eligible incident can be investigated under your configuration.
Incidents preserve the evidence chain: signal, aggregation rule, investigation steps, affected endpoints, approvals, actions, and verification.
How is Incident Intelligence different from normal monitoring?
How is Incident Intelligence different from normal monitoring?
GenticFlow includes endpoint monitoring and alerts. Incident detection adds a shared record when related evidence meets a supported incident type’s criteria, with affected endpoints, timing, and evidence for follow-up.
What does the agent baseline?
What does the agent baseline?
The agent learns supported endpoint metrics such as CPU, memory, disk, and connectivity measurements. Event-based detections also use typed source evidence. Live service and process diagnostics do not imply automatic per-process baselines or a model of every user and role.
What happens when an issue starts spreading overnight?
What happens when an issue starts spreading overnight?
Scheduled analysis checks qualifying observations against supported incident criteria. A published incident records scope and evidence and can feed configured notifications or tickets. Eligible investigations run separately; candidate observations do not trigger incident responses.
Can incidents trigger a response?
Can incidents trigger a response?
Yes. Published incidents can feed configured tickets and notifications. Automatic investigation and Hero workflow triggers depend on the incident type and configuration. Candidate observations do not create tickets, notifications, investigations, or incident workflows. Follow-up actions retain their own permissions and approvals.
Can technicians ask fleet-wide questions outside an incident?
Can technicians ask fleet-wide questions outside an incident?
Yes. Fleet Investigations can be started directly, scoped by organization, connector, group, or tag. Read-only checks can also sweep every eligible endpoint for live conditions such as a running process, a service state, disk pressure, a pending reboot, or connectivity, with filterable results and an export.
See what is spreading before users flood the queue.
GenticFlow groups qualifying device signals into incidents with scope and supporting evidence. Eligible incidents can be investigated under your configuration to explore possible causes and guide the response.