A check produces current evidence and status.
Shopify monitoring alerts
Know when a real Shopify problem starts — and when it is actually resolved
GO4 turns qualifying monitoring failures into durable incidents, keeps repeated observations in the same context and notifies your team when a problem opens and when recovery is confirmed.
From signal to incident
A monitoring signal is not automatically an incident
GO4 keeps raw observations, check status and incident escalation as separate layers. Only a qualifying problem that reaches the check’s incident policy becomes an open incident.
Impact, current rules and effective status determine whether the problem is actionable.
The configured incident threshold prevents every isolated signal from immediately becoming a new incident.
A qualifying problem becomes one durable incident and can trigger its new-problem notification.
A later healthy state can close the incident and complete the notification loop.
Incident policy belongs to the check lifecycle, not to every individual observation.
That separation helps keep setup states, deferred work, informational findings and intentionally muted evidence out of the operational alert stream.
Alert fatigue control
One problem stays one incident — not a stream of duplicate alerts
When the same qualifying problem is observed again, GO4 updates the open incident instead of opening a new one for every repeat.
Repeated observationsSame problem, continuing context
First qualifying failureIncident opens and the new-problem notification is sent.
OpenFailure observed againFailure count, last seen and current problem context are updated.
UpdateFailure observed againThe same open incident continues to carry the problem.
UpdateHealthy evidence returnsThe incident can close and recovery is notified.
RecoveredKeep the team informed without notifying on every repeat
Slack and Telegram are delivery channels. The incident remains the durable state that accumulates repeat observations until recovery.
One open incident per continuing problemRepeat failures update contextRecovery closes the loop
What reaches the incident layer
Separate actionable problems from monitoring noise
GO4 preserves evidence without forcing every signal into the same operational meaning.
Critical monitoring failures
Failures with operational impact can drive the main incident lifecycle when their policy is met.
Can open incidentSEO, audit and quality problems
Supported quality checks can use incidents when that check type and configuration allow it.
Policy dependentVisible evidence without active impact
Muted findings and ignored providers stay available as context without driving active status, incidents or alerts.
No incident impactControlled skip or setup state
Deferred work is not a monitoring failure and does not increase the failure threshold or open an incident.
No failureNotification delivery
Send the incident to the channels your team already watches
GO4 currently delivers incident and recovery notifications through outbound Slack and Telegram destinations while keeping the dashboard incident as the source of truth.
New incident / recoveryGO4 incident lifecycle
SlackWorkspace destination for new incidents and recovery updates.
OutboundTelegramWorkspace destination for new incidents and recovery updates.
OutboundNotifications point back to the monitoring context
The message tells the team that something needs attention. The incident and underlying monitoring evidence keep the fuller operational context.
Workspace-scoped destinationsNew-problem and recovery lifecycleNo raw provider secrets in customer-facing UI
Incident context
Keep the problem history after the notification is gone
A chat notification is transient. GO4 keeps the incident record tied to its monitored site and check so the team can see whether the problem is still active and how often it has repeated.
Incident recordStorefront purchase path
OpenSiteShopify storefront
SeverityCritical
Failure count4
Opened09:42
Last seen10:07
StatusOpen
The incident tells you what needs attention. The monitoring layer provides the evidence.
From the incident, investigation stays connected to the check, current findings and the evidence produced by the monitor that detected the problem.
Check historyCurrent findingsBrowser evidence when availableAudit / Radar / JS Agent context
GO4 does not pretend that the incident itself proves root cause. It keeps the operational thread while the relevant monitoring layer provides the evidence.
Recovery closes the loop
Knowing it recovered matters as much as knowing it failed
When the monitored condition returns to a healthy state, the existing incident can close through the central lifecycle and a recovery notification can be sent.
StateOpenFailures4Last seen10:07
StateClosedVerified10:18NotificationRecovery sent
One operational layer across GO4
Different monitors detect different problems. Incidents turn the actionable ones into one workflow.
Page health, browser behavior, journeys, SEO, Shopify audits, third-party dependencies and real-browser signals keep their own evidence models. The incident lifecycle sits above them without merging those monitoring systems together.
Page MonitoringBrowser LabAction JourneysSEO & AuditsExternal RadarJS Agent
Operational layerIncidents
Qualifying problems become durable operational state without collapsing the underlying evidence models into one monitor.
Alert → investigate → recoverSlack / Telegram delivery plus dashboard history and recovery.
Incident & alert questions
What merchants usually want to know about GO4 notifications
The alerting layer is intentionally tied to monitoring state so notifications reflect real incident lifecycle instead of becoming a separate message stream.
Does every failed check create an incident?
No. Incident creation depends on the effective monitoring result, impact, the check type’s incident behavior and its configured failure policy. A single observation does not automatically mean a new incident.
Will GO4 notify me every time the same problem is detected?
No. Repeated observations of the same continuing problem update the existing open incident. GO4 does not send a new “incident opened” notification for every repeat.
Which notification channels does GO4 currently support?
The current product uses outbound Slack and Telegram destinations for incident and recovery notifications.
Does GO4 notify me when a problem recovers?
Yes. When the central incident lifecycle closes an open incident after healthy evidence returns, the configured alert channels can receive the recovery notification.
Do muted findings or ignored providers create incidents?
No. They remain available as context but do not contribute to active status, incident creation or alerting while muted or ignored.
Does a deferred check create an incident?
No. Deferred means the iteration was intentionally skipped or is waiting on a valid setup/runtime condition. It is not a monitoring failure and does not increase the consecutive-failure threshold.
Can quality problems create incidents?
Yes, where the check type supports quality incidents and its configuration allows them. Informational-only evidence does not by itself raise the effective status to warning.
Where can I review previous incidents?
Open and closed incidents remain available in the GO4 incident history within the applicable retention and cleanup lifecycle.
Turn monitoring into an operational loop
Detect the problem, notify the team and know when the store is healthy again
Use GO4 incidents as the durable operational thread across your monitoring layers while Slack and Telegram keep the right people informed.
One incident for a continuing problemSlack & Telegram notificationsRecovery closes the loop