What Logystera actually lets you see
Your WordPress or Drupal site returns 200 OK. Uptime monitors say "healthy." But logs tell a different story - emails failing, cron stopped, errors swallowed, queues growing. Logystera reads those logs and makes the truth visible.
See what actually happened - not what appeared to happen
Uptime monitors check if the server responds. Logystera checks what your application actually did. Every HTTP request, every email attempt, every cron execution, every authentication event - captured through hooks and event subscribers, turned into structured events you can query.
Your contact form returned 200 but wp_mail() silently failed. Your site loaded fine but cron hasn’t executed in 422 days. Logystera shows what actually happened, not what the HTTP status implied.
What you see
Detect silent failures the moment they start
The most damaging failures are the ones that don’t produce errors. A form that submits but never delivers. A cron that stops but the site keeps loading. A payment callback that returns malformed JSON but the checkout still shows “processing.”
Logystera watches for the absence of expected events, not just the presence of errors. If cron hasn’t run in 24 hours, if no emails have been sent since yesterday, if a queue depth keeps growing - you know immediately.
Silent failures Logystera catches
Metrics derived from logs - not pre-defined
Traditional monitoring tracks metrics someone decided to instrument. Logystera derives metrics from what actually happens. Every log event passes through pre-built definitions that extract counts, rates, durations, and patterns automatically.
A single log line can produce multiple metrics. A failed login becomes both a security signal and an authentication rate metric. A slow request becomes both a latency measurement and a route-level performance indicator.
How it works
Log event → one line captured by plugin/moduleProcessor → applies pre-built definitionsDerived metrics → counters, rates, trendsDashboards & alerts → ready immediatelyAlerts built for WordPress and Drupal - not for you to configure
You don’t define what “too many failed logins” means. It’s already defined - tuned against real production WordPress and Drupal sites. Cron hasn’t run in 24 hours. Email delivery dropped to zero. 10 failed logins in 5 minutes. PHP fatals on every request. Every alert is ready the moment you install.
Need a custom threshold for your site? Custom detection rules tailored to your environment on paid plans. No rules files to edit, no deployments, no code.
What an alert looks like
Alerts that include evidence - not just a notification
When something fires, the alert includes the exact log events that triggered it. Not “error rate increased” - but which errors, from which files, at what time, and how frequently. You can act immediately because the alert is the investigation.
Alerts are delivered via email or webhook. Bundling collapses bursts into single notifications. Suppression prevents re-alerting for known issues. Every alert outcome - sent, suppressed, bundled - is tracked as a metric.
What makes alerts different
Every event becomes an auditable record
Login attempts, configuration changes, permission escalations, REST API calls, plugin activations, file modifications - all captured, timestamped, and queryable. When someone asks “what happened on Tuesday?” you have the answer.
Logystera doesn’t sample. Every event that matches a definition is captured, ingested, and stored. The audit trail is complete - not an approximation.
Events captured
