How Logystera works

The signal layer

The integration reads structured activity signals from your application, not raw log lines. Authentication attempts. Outbound mail. Cron and scheduled work. PHP errors. Configuration changes. Database events. Request shape. Plugin and module lifecycle. Each signal is a small, well-defined event with a stable shape and a small payload — the structure of the activity, not its contents.

• No request bodies, form contents, comment text, post bodies, or session data. A request signal carries the path, status, route group, user-agent, timing. Not the content of the request or the response.
• No message bodies, no email addresses. A mail signal carries the delivery outcome. Not the email.
• Identifiers are hashed. Usernames travel as one-way hashes with length. Sensitive configuration values travel as hashes of their before-and-after.
• File-edit signals carry behavior, not content. Size delta, a few high-signal heuristics, never the file.
• Each signal type is individually toggleable from the integration's admin UI. The operator on your end owns the trust boundary, not us.

The design test we apply to every signal type: can we describe what happened on the site without describing what the user said? If yes, the signal ships. If no, it doesn't.

The dispatcher boundary

Signals are buffered locally before they leave your server. If our gateway is unreachable, the buffer holds. If the outage lasts longer than the buffer, the integration tells you it dropped events — the dropped count is itself a signal, surfaced like any other.

Each batch is signed and sent over HTTPS. Backoff is exponential and bounded; once the integration sees enough trouble, it stops attempting and waits, rather than hammering a degraded endpoint. A short outage on our side is invisible to your monitoring. A long one degrades gracefully, and the degradation is visible to you.

The detection model

Once signals reach the platform, rules evaluate them. A rule is a set of conditions on incoming signals combined with a threshold over time, plus an optional suppression policy and the shape of what to deliver when it fires.

The model is deterministic. Rules describe what unhealthy looks like, and a threshold says how persistent the unhealth has to be before a person is involved. “Mail delivery is failing” is a configured detection over the mail signal. “Cron has stopped” is a configured detection over the cron heartbeat. “Authentication behavior shifted” is a configured detection over auth signals grouped by source.

There is no model deciding what counts as anomalous. The conditions are deterministic; the thresholds are configured; the outcomes are reproducible.

Noise control

Detection accuracy is half the job. The other half is making sure a single persistent problem doesn't produce two hundred alerts.

Suppression silences your phone for a configurable window after a rule fires. While suppression is active, the underlying signal keeps being evaluated — we don't lie about whether the condition is still happening. If the condition persists when the suppression window expires, the next alert fires. Suppression silences your phone, not the truth.

Per-channel rate limits keep a single unusual day from flooding the destination. Bundling collapses a burst of related events into one alert when the rule expects burst behavior. None of this is configurable through a feedback loop; once a rule is defined, its behavior is predictable.

What an alert contains

When a rule fires, the payload carries:

• What the rule was, in human terms, and what it matched on
• Severity
• When it started, and how recently it was re-evaluated
• The signals that triggered it, as evidence — enough to act on, not enough to leak
• What it affects (which site, which subsystem)
• A link back to read the underlying state in context

Every delivery attempt is recorded. The alert is a tracked dispatch, not fire-and-forget.

Channels

Alerts are delivered via webhooks — generic, Slack-formatted, Microsoft Teams-formatted — and email. For production operations, webhooks into your existing on-call or incident tooling are the path we recommend; they're reliable, integrate cleanly with your runbook, and don't put your incident response inside someone else's inbox.

Determinism

Given the same signals and the same rule definitions, the engine produces the same detections. Not approximately. Same.

This is the “not AI” commitment, stated operationally. The detection layer doesn't learn from how you read alerts. It doesn't adjust based on time of day, on analyst behavior, on which alerts got acknowledged. Detection is the same on Tuesday at 3 AM as on Thursday at lunchtime. We test for this in our build pipeline; replays that diverge fail the build.

Reports — the interpreted weekly summary — are a separate product, and they are AI-assisted with human review. Detection is not.

Operational discipline

The metric system is constrained by design. Each metric definition declares the labels it produces and what values those labels can take; values outside the declared set are bucketed, not silently expanded. This keeps the system well-behaved when one definition is misconfigured: a noisy metric stays bounded instead of poisoning the store. Per-fingerprint memory is bounded by the same principle. We'd rather fail loudly at definition time than silently at the storage layer.

Hosted today; self-hosting on request

The platform is delivered as a hosted service from the European Union. Self-hosting is available for organizations that need it — typically regulated industries with data-residency requirements the hosted service can't fully meet — and is engaged through a contracted arrangement, not as a self-serve download. It is real, used in production, and operationally non-trivial for both sides. If your situation makes self-hosting necessary, that is a conversation worth having early.

What this isn't

• Not an APM. No tracing through application code. If you need flame graphs and span-level latency, this isn't the layer.
• Not a SIEM. No raw log retention, no external threat-feed correlation, no compliance-bounded retention out of the box. A smaller, more specific surface: the behavioral signals your application emits, watched continuously.
• Not a machine-learning anomaly detector. Detections are configured. The system knows cron has stopped because it is configured to notice when cron stops — not because a model decided that was unusual today.
• Not a runtime profiler, not a log-search platform, not a status page. Adjacent to all three; replaces none.

What it is: a behavioral monitoring layer that watches the operational systems your team runs, derives a continuous picture of how they are behaving, and tells you the moment that picture changes — with the evidence.