// PROJECT_ARCHIVE LOADED

> Projects_

Work from the lab

— systems built, problems solved.

[ View Archive ]
scarlett@lab:~$ _

ARCHIVE_CONTROLS

STATUS
2 records indexed tags: ACF Community Gaming Monitoring Plugin Security +1

PROJECT_FILES

2 records
INDEX_COMPLETE Select a file to view case details

CASE_FILE // SENTINEL

STABLE

Sentinel+

YEAR Ongoing
STACK PHP / Javascript / Wordpress / GSAP
ROLE Design & Development
TAGS Wordpress / Plugin / Security / Monitoring
MAINT MAINTAINED
PROD PRODUCTION
SCALE SINGLE SITE / SMALL TO MEDIUM PROJECTS
RISK LOW

Sentinel started life as an internal plugin for JPSNT.

As JPSNT grew, basic error logging stopped being useful. The site was no longer failing in obvious ways. Problems showed up as patterns instead. Repeated warnings. Memory usage creeping up over time. Hooks firing more than once. Requests that were fine most of the time and slow at exactly the wrong moment.

Debugging became reactive. Something would break, and then time would be spent trying to reconstruct what led up to it using partial logs and guesswork. The information needed to understand the problem usually existed, but it was scattered or missing when it mattered.

The original goal was not to build a monitoring product. It was to answer simple questions consistently. What happened. When it started. Whether it was new or recurring. Whether something changed shortly before.

As the internal tooling expanded to include better error categorisation, request context, memory tracking, and batch logging to reduce overhead, it became clear the system being built was not specific to JPSNT. The same failure patterns showed up across most WordPress projects, especially those maintained by one person or a small team.

Sentinel was split out into its own plugin once it became obvious it was solving a wider problem. Sentinel+ exists as the extended version of that system, focused on providing useful signals early, without adding noise or operational complexity.

  • Sentinel+ is not a full observability or APM platform.

  • It does not try to monitor everything, only what tends to matter first.

  • It does not provide live dashboards or second-by-second telemetry.

  • It does not replace good hosting, sensible architecture, or maintenance.

  • It does not attempt to abstract WordPress away or hide how it works.

  • It does not collect, sell, or transmit site data to third parties.

  • It does not assume constant attention or daily review.

  • It does not require a dedicated operations or security team.

  • It does not aim to prevent every failure.

  • It accepts that some problems only become clear in hindsight.

  • It accepts that fewer, clearer signals are more useful than exhaustive logs.

01
Batch log events instead of writing to the database immediately Direct writes during high-frequency events caused unnecessary load and made failures worse under pressure. Batching reduces overhead and keeps logging from becoming the problem it is meant to observe.
02
Categorise events by type and severity at capture time Raw logs are cheap to collect but expensive to interpret later. Assigning meaning early makes the data usable without post-processing or guesswork.
03
Focus on early warning signals rather than fatal errors only By the time a fatal error occurs, the useful context is often already gone. Warnings, memory trends, and repeated edge cases appear earlier and provide more time to react.
04
Track memory usage across the request lifecycle Memory-related issues in WordPress rarely fail immediately. Tracking usage over time makes slow leaks and heavy operations visible before they cause outages.
05
Detect duplicate events within a single request WordPress hooks can fire multiple times under normal conditions. Without deduplication, logs become misleading and inflate the perceived severity of issues.
06
Keep logging local to the site by default Shipping data elsewhere adds complexity, cost, and trust concerns. Keeping data local makes the system simpler to reason about and easier to adopt.
07
Treat admin, frontend, and background requests differently The same event can have very different implications depending on where it occurs. Context reduces false alarms and improves relevance.
08
Prefer summaries and digests over constant notifications Frequent alerts train users to ignore them. Periodic summaries surface patterns without demanding constant attention.
09
Integrate directly with commonly used third-party WordPress plugins Many critical issues originate inside plugins rather than core. Native integration allows Sentinel to capture meaningful context instead of treating all failures as generic PHP errors.
10
Keep Sentinel usable without Sentinel+ The core plugin must stand on its own. Sentinel+ enhances insight but is not required for the system to function correctly.
v1.1.0 Introduction of Sentinel+ analysis and extended monitoring CURRENT
v1.1.1 Refinement of core monitoring and expansion of Sentinel+ insights PLANNED
📄

Sentinel+ is a WordPress monitoring plugin for sites that actually matter.
It tracks PHP errors, login problems, HTTP failures, memory warnings, slow requests and other noisy events into a single, readable log.
Batch logging and cron-based processing keep the plugin light, while dashboards and digests surface the important patterns instead of spamming you.
Built for single developers and small teams who want early warning and clear context before a site tips over, not just an error screen after the fact.

3 captures
Dashboard Primary dashboard showing Sentinel Metrrics
Log Sentinel Activity log. Showing all captured events and their details
Settings Sentinel settings. Sentinel is designed to be integrated into your site how you need it to be.,
$
REPORT_COMPLETE sentinel.casefile
EOF
scarlett@lab:~$ _