Understanding scans, alerts, events and timestamps

Objective

This article explains what Securantis means by “scans”, “alerts” and “events”, how these items arrive in your client area, why their timestamps can differ and how to respond. It is intended for account administrators managing multiple sites and licenses from the Securantis client area.

Why this matters

Understanding these concepts helps you to:

• correctly interpret a report or notification;
• determine whether an action (license suspension, alert sending, license creation) originated from a scan, a webhook or a manual action;
• diagnose time offsets and alert delays.

Definitions and roles

• Scan: the result of a scan or check executed by the agent installed on your site (or by a cloud-side scan). A scan produces a structured report (files detected, vulnerabilities, suspicious activities) and can generate events.

• Event: raw or structured entry representing an action or a state (for example: blocked request, file modification, successful/failed admin login, license change). Events are the raw material displayed in logs and useful for investigations.

• Alert: notification derived from one or more events/scans. An alert is intended to draw attention (by email, dashboard or summary) when a threshold or rule is triggered.

Data flow (simplified)

1. The agent on the site performs a scan or detects an event locally.
2. The agent sends the data (events/scan report) to the Securantis cloud.
3. The cloud normalizes and stores these entries, correlates them and may generate alerts according to your settings.
4. Alerts are sent (or queued) and visible in the client area.

Notes on license synchronization and external events

• Events originating from external services (e.g. a Stripe payment notification) are processed by separate mechanisms that can change license state (creation, suspension, reactivation). These processes are designed to avoid duplicates (locking/transaction) and rely on the current subscription state.

• Some automatic license suspension actions are triggered by billing events (for example, payment failure or subscription cancellation). Suspension prevents license use, but the final decision to restore or delete a license remains human.

Timestamps: why dates can differ

Several timestamps may appear for the same entry:

• source timestamp: the moment when the event was observed on the site (by the agent) or by an external service;
• ingestion timestamp: the moment when Securantis received and persisted the event;
• display timestamp: local transformation (for example in the browser) which may apply a timezone or a different format.

Common causes of offset

• Agent local time not synchronized (NTP missing): the agent may mark an event with an incorrect local time.
• Network latency or queues: a large scan report may take a few moments to arrive and be processed before appearing. Email sends follow the outgoing queue and may be delayed.
• Webhooks and retries: external webhooks (payments) may be resent; the service filters repeats but the Stripe timestamp remains tied to the original event.

How to correctly read time information

1. Verify the origin of the entry (agent vs external service). The origin is generally indicated in the event detail.
2. Prefer the source timestamp to analyze the timeline on the site (e.g. an intrusion).
3. Use the ingestion timestamp to trace when Securantis actually became aware of the event (useful to correlate with automated actions, such as a license suspension).
4. If you see multiple timestamps, note that they reflect different processing stages and a small offset is normal.

Prudent settings and best practices

• Time synchronization: ensure your servers/sites use NTP or a reliable time service. A correct system clock reduces false diagnostics.
• Alert rules: favor reasonable thresholds (avoid being notified on the first unconfirmed anomaly). Configure precise recipients for critical alerts.
• Queue monitoring: if you manage a large fleet of sites, monitor delivery delays for reports and emails (frequent delays indicate saturation or an infrastructure issue).

Common errors and quick diagnostics

• Alert received late: check the agent status, network connectivity and cloud processing metrics. Confirm whether the agent actually sent the event (agent logs).
• Agent timestamp off: confirm the server NTP/time configuration and the OS timezone.
• Duplicate events appearing: check if the agent restarted and resent data; verify if external webhooks were re-emitted. The system attempts to prevent duplicates, but simultaneous cases can produce close entries.
• Unexpected license change after payment: review the billing-related event history. Subscription statuses and payment webhooks (success/failure/cancellation) are the usual triggers. Manual synchronization is available from the client area if needed.

Step-by-step troubleshooting

1. Identify the problematic item (missing/late alert, inconsistent timestamp, suspended license).
2. View the event/alert detail in the client area to determine the origin (agent, cloud, third-party service).
3. If origin is agent: check the agent state and logs on the site, time synchronization and connectivity.
4. If origin is external (payment): check the provider notifications (e.g. Stripe) and the correspondence in the billing history.
5. For suspensions or license creations, consult the license history: you will see the context (subscription, quantity, synchronization time).
6. If necessary, trigger a manual license synchronization from the client area to force immediate reconciliation.

Precautions and security rules

• Quarantines, restorations and file deletions always require a human decision. Securantis does not automatically delete or restore critical items without explicit confirmation.
• Never transmit passwords or secret keys by email or chat. For any access required for a paid intervention, we use the secure client area after payment.

When to contact support

Contact Securantis support when:

• you observe systematic timestamp offsets after verifying NTP;
• expected events/scans do not appear despite an online agent;
• licenses are suspended without an apparent billing event;
• you need help interpreting a series of correlated alerts.

Information to provide to speed assistance

• identifier of the affected site/license;
• timestamps (source and ingestion) of the events or alerts;
• screenshot of the alert detail;
• state and version of the installed agent and the server local time.

Expected outcome after intervention

After verification, you will receive:

• explanation of the timeline (origin and timestamps);
• corrective measure (agent setting, NTP correction, license re-synchronization) or recommendations if manual action is required;
• follow-up until resolution or indication of a paid intervention if necessary.

Summary

Scans, events and alerts are complementary layers: scans produce events, events feed alerts. Timestamps correspond to different stages (source and ingestion) and small offsets are normal. Check agent time synchronization and connectivity before opening a ticket to save time. Support is available if you need an in-depth diagnosis or assisted intervention.