The Code Block is a Gutenberg block (cloudscale/code-block) and shortcode for syntax-highlighted code. Syntax highlighting is powered by highlight.js 11.11.1, bundled locally, supporting 190+ languages with auto-detection.

Block and shortcode usage:

• Gutenberg block — search for “CloudScale” in the block inserter or type /code. Language, theme override, title, and line numbers are configurable in the block sidebar.
• Shortcode:
  ⚡ Powered by CloudScale

  functions.php

  Copy

  your code here

  . Supported attributes: lang (any highlight.js language alias), title (filename label above the block), theme (per-block dark/light override).

Features:

• Auto language detection — highlight.js analyses the code and picks the most likely language. Override manually in the block sidebar when detection is wrong.
• 14 colour themes — Atom One (default), GitHub, Monokai, Nord, Dracula, Tokyo Night, VS 2015, VS Code, Stack Overflow, Night Owl, Gruvbox, Solarized, Panda, Shades of Purple. Each theme has a dark and light variant; the toggle stores the reader’s preference in localStorage.
• Copy to clipboard — uses the Clipboard API with fallback to document.execCommand('copy').
• Line numbers — toggle per block. Line numbers are rendered via CSS counter so they are not included when a reader copies the code.
• Paste with fence detection — paste a Markdown-fenced code block (e.g. ```bash … ```) directly into the editor and the language is set automatically.

Automatic INI/TOML fragment repair: When you paste Markdown with INI/TOML fenced code into Gutenberg, bare [section] headers are pulled out and turned into core/shortcode blocks, fragmenting your code. CloudScale Devtools detects this and silently merges the fragments back before you see them. A toast confirms when it happens.

Requirements: WordPress 6.0+, PHP 7.4+.

The Code Block Migrator (Tools → CloudScale Cyber and Devtools → Migrate tab) converts legacy code block shortcodes and blocks from other plugins to CloudScale Devtools blocks in a single batch operation.

Supported source formats:

• WordPress core <!-- wp:code --> and <!-- wp:preformatted --> blocks.
• <!-- wp:code-syntax-block/code --> blocks from the Code Syntax Block plugin.
• Legacy [code], [sourcecode], and similar shortcodes — language attribute is preserved where present.

Migration workflow:

1. Scan — queries wp_posts for all posts and pages containing the supported patterns. Results list post title, status, date, and block count.
2. Preview — shows a before/after diff for each post. No database writes occur at this stage.
3. Migrate single — converts one post at a time and flushes the post cache.
4. Migrate all — processes every remaining post in a single AJAX request. For large sites (>500 posts), run during low-traffic periods.

Always take a backup before running the migrator. The conversion modifies post_content directly in the database and there is no undo.

The Hide Login URL feature moves your WordPress login from the default /wp-login.php to a custom URL slug of your choice. Requests to /wp-login.php return a 404 to automated scanners and bots.

How it works: The feature hooks into init and rewrites the login request transparently — no redirect occurs, so there is no latency penalty. It overrides login_url, lostpassword_url, and register_url filters so all WordPress-generated links point to your custom slug automatically. WP-CLI, REST API, XML-RPC, and WP Cron connections are unaffected.

Setup: Tools → CloudScale Cyber and Devtools → Login tab → enter your chosen slug (e.g. my-login) and save. Your login URL becomes https://yoursite.com/my-login. Keep a note of your slug — if you forget it you can recover it by deactivating the plugin.

Session Duration: Also on the Login tab, you can set a custom session duration (in days). When set, login cookies are issued with that lifetime so users stay logged in without re-authenticating on every visit.

CloudScale Devtools supports three 2FA methods, all configurable under Tools → CloudScale Cyber and Devtools → Login tab.

Email Code

After a successful password login, a 6-digit code is emailed to the user’s registered address. The code expires after 10 minutes. No third-party service is required — the code is generated and verified entirely on your server.

TOTP (Authenticator App)

Generates a QR code that the user scans with any RFC 6238–compliant authenticator app (Google Authenticator, Authy, 1Password, Bitwarden, etc.). The 6-digit code rotates every 30 seconds. Setup is done from the Login tab via a wizard: scan QR → enter code to verify → done.

Passkeys

See the Passkeys (WebAuthn) section below for full details.

Enforcement & Grace Logins

• Force 2FA for all admins — when enabled, all users with the manage_options capability must complete 2FA setup before they can access wp-admin.
• Grace logins — configures how many times a user can log in without 2FA before they are required to set it up. Useful for rolling out 2FA across a team without locking anyone out immediately.

Passkeys use the FIDO2/WebAuthn standard to replace or supplement passwords with a biometric or hardware key. The private key never leaves the user’s device — your server only stores the public key.

Supported authenticators: Face ID and Touch ID (macOS/iOS), Windows Hello, Android biometrics, and hardware security keys (YubiKey, etc.).

Browser support: Chrome 108+, Safari 16+, Edge 108+, Firefox 122+.

Key properties:

• Phishing-resistant — the key pair is domain-bound; a cloned login page on a different domain cannot use it.
• Per-device registration — register multiple devices with individual labels. Remove any device at any time from the Login tab.
• Test without logout — after registering a passkey you can verify it works from the Login tab without signing out first.

Registration: Tools → CloudScale Cyber and Devtools → Login tab → Passkeys section → click Register and follow your browser/OS prompt. Give the device a recognisable label (e.g. “MacBook Touch ID”).

The Brute Force Protection feature rate-limits repeated failed login attempts on a per-username basis, locking out attackers before they can exhaust your password space.

Configuration (Tools → CloudScale Cyber and Devtools → Login tab):

• Max attempts — number of consecutive failed logins before a lockout is triggered (default: 5).
• Lockout duration — how long the account is blocked after the threshold is reached (configurable in minutes).

The lock is per-username, not per-IP — this stops distributed attacks spread across multiple IPs. Failed attempts and lockout state are stored as WordPress transients — no extra database tables. Lockouts clear automatically when the transient expires. Successful logins reset the counter.

Works alongside 2FA: Brute force protection fires at the password stage, before any 2FA challenge. An attacker cannot reach the 2FA prompt if they have already been locked out.

The Test Account Manager creates short-lived subscriber-level WordPress accounts with application passwords — designed for Playwright, Cypress, and other automated testing pipelines that need to authenticate against the WordPress REST API without storing production credentials in CI configuration.

How It Works

When enabled, clicking Create Test Account generates a new subscriber account with a random username (e.g. csdt-test-a1b2c3) and an application password. Credentials are displayed once only — copy them immediately. The account and its app password are automatically deleted when the TTL expires.

The feature restricts app passwords to test accounts only — all production accounts remain blocked. This means you can have the security benefit of disabled app passwords for regular users while still giving CI pipelines a safe authentication path.

Configuration

• Default TTL — how long an account lives before automatic deletion: 30 min, 1 hour, 2 hours, or 24 hours.
• Single-use — delete the account immediately on the first successful authentication. Useful for one-shot test runs; may cause issues if Playwright retries a failed request.

Using Credentials in Playwright

After creating an account, the panel shows copy buttons for:

• JSON — paste into a .env file or a Playwright fixture
• curl example — test the credentials from the command line

The REST URL shown is the base URL for authenticated API calls using Basic Auth with the app password.

Active Account List

The panel shows all currently active test accounts with their expiry time. Click Revoke on any account to delete it immediately rather than waiting for the TTL.

Access the audit at Tools → CloudScale Cyber and Devtools → Security tab. Two scan modes are available:

Run AI Cyber Audit (Standard)

The fast scan (~15–30 seconds). Collects server-side configuration data and sends it to your chosen AI model:

• PHP and WordPress core versions
• Active plugins and themes (versions, known vulnerability flags)
• File permissions on key files and directories
• Exposed debug flags (WP_DEBUG, WP_DEBUG_LOG, SCRIPT_DEBUG)
• User accounts, roles, and 2FA coverage
• Brute-force protection configuration
• Key wp-config.php security constants (DISALLOW_FILE_EDIT, FORCE_SSL_ADMIN, table prefix, secret key strength)
• WordPress version display and XML-RPC exposure

Run AI Deep Dive Cyber Audit

The comprehensive scan (~30–90 seconds). Extends the standard scan with:

• Live HTTP header inspection — Content-Security-Policy, HSTS, X-Frame-Options, X-Content-Type-Options, Permissions-Policy, Referrer-Policy, and CORS (Access-Control-Allow-Origin).
• Endpoint exposure probes — /wp-json/wp/v2/users (user enumeration), XML-RPC, /wp-cron.php, open redirect test, and upload URL accessibility.
• Directory listing checks — verifies that /wp-content/plugins/ and /wp-content/themes/ do not return a browsable file listing (a common information disclosure risk).
• SSL/TLS certificate — expiry date and days remaining.
• Weak TLS protocol detection — tests whether your server still accepts connections over TLS 1.0 or TLS 1.1 (deprecated since 2021; rejected by modern browsers).
• DNS email security — SPF, DMARC, and DKIM records for your sending domain. DKIM is probed across 12 common selectors (google, default, mail, selector1, selector2, sendgrid, etc.).
• PHP end-of-life status — flags PHP versions that have reached end-of-life and are no longer receiving security patches, with the exact EOL date.
• Static code analysis — scans active plugin PHP files for known vulnerability patterns: eval(), base64_decode() on user input, shell_exec()/system(), dynamic include/require, obfuscated variable names, and suspicious SQL construction.
• AI code triage — top static findings are sent to an AI model for classification before the main audit (see AI Code Triage below).

Results from all checks are merged and weighted (internal config 45%, external exposure 55%) into a single scored report with cross-correlated findings — for example, flagging when weak TLS is combined with a missing HSTS header, or when PHP is EOL and also has plugins with known vulnerabilities.

AI Providers

The audit supports two AI providers. Select your preferred provider and enter your API key on the Security tab settings panel:

• Anthropic Claude — uses the Claude API (api.anthropic.com). Get an API key at console.anthropic.com. Default models: Claude Sonnet 4.6 (standard), Claude Opus 4.7 (deep dive).
• Google Gemini — uses the Gemini API (generativelanguage.googleapis.com). Get an API key at aistudio.google.com/apikey. Default models: Gemini 2.0 Flash (standard), Gemini 2.5 Pro (deep dive). A free tier is available.

You can customise the model selection and edit the system prompt directly in the settings panel to tune the analysis for your environment.

How Scans Run (No Timeout Risk)

Scans can take 30–120 seconds. To avoid HTTP gateway timeouts, CloudScale Devtools uses fastcgi_finish_request() to close the browser connection immediately after the scan starts, then continues running the analysis in the same PHP-FPM worker in the background. A progress bar updates every 3 seconds via polling until the result is ready. This approach does not depend on WP Cron — DISABLE_WP_CRON and cron configuration have no effect on on-demand scans.

External Services Used

When a scan runs, the following external requests are made:

• AI provider API — scan data (plugin list, PHP config, headers, etc.) is sent to the Anthropic or Gemini API for analysis. No personally identifiable user data is included. Review each provider’s privacy policy: Anthropic · Google.
• Your own site (deep dive only) — the plugin makes HTTP requests to your own site’s public URLs to check security headers and endpoint exposure. No data leaves your server other than the final summary sent to the AI.

API keys are stored in wp_options and never exposed to the browser. The Security tab displays a masked version of the stored key.

Access Control

The Security tab requires the manage_options capability (administrators only). All AJAX endpoints are protected by nonce verification and capability checks.

The Quick Fixes panel (Security tab, above the AI Audit controls) shows a checklist of common WordPress security misconfigurations. Each item displays its current status and, where automation is possible, a one-click fix button.

What It Checks

• debug.log exposed — checks whether wp-content/debug.log exists and is publicly accessible. The fix button moves the file to a directory outside the web root and rewrites the WP_DEBUG_LOG constant in wp-config.php to point to the new safe path, preventing the file from being recreated at the old location.
• WordPress version displayed — checks whether wp_generator is emitting your WordPress version in page <head>. The fix removes the generator meta tag.
• XML-RPC enabled — checks whether /xmlrpc.php is accessible. The fix disables it via a filter (unless you have WooCommerce or JetPack which require it).
• Application passwords — checks whether WordPress application passwords are enabled. The fix disables them unless the Test Account Manager feature is active (which requires app passwords for its CI pipeline accounts).
• Directory browsing — checks whether Apache/Nginx is serving directory listings for your uploads folder.
• File editing in wp-admin — checks whether the built-in theme/plugin code editor is enabled (DISALLOW_FILE_EDIT).

Status Indicators

Each item shows one of:

• ✓ Fixed — the issue is not present (or has been resolved).
• ⚠ Action needed — the issue is present; a fix button is shown if automation is available.
• ⚠ Warning — fixed but with a caveat (e.g. wp-config.php was not writable so only a partial fix was applied).

The checklist refreshes automatically after each fix is applied.

Every scan result — both on-demand and scheduled — is automatically saved to scan history. The last 10 results are kept, stored in wp_options so they survive across sessions and server restarts.

The history table (Security tab, below the scan controls) shows:

• Scan type (Standard or Deep Dive)
• Date and time the scan completed
• Overall score and top-level risk rating

Click any row to instantly reload that scan’s full AI report into the results panel — useful for:

• Comparing your security posture before and after making changes
• Reviewing a scan result after returning to a page that had been navigated away from
• Sharing a specific scan with a colleague (results are stored server-side, not in the browser)

The Scheduled Scans panel (Security tab) lets you run a deep dive cyber audit automatically on a recurring schedule, without having to visit the admin panel.

Configuration

• Schedule — choose Daily or Weekly.
• Email alerts — when enabled, the AI audit summary is emailed to the administrator’s registered email address after each scheduled scan completes.
• ntfy.sh notifications — enter an ntfy.sh topic to receive a push notification on your phone when a scan completes. Useful for monitoring sites without checking email. The notification includes the overall risk score and a summary of the top findings.

How Scheduled Scans Run

Scheduled scans are dispatched via WP-Cron. The scan runs as a background PHP process (same mechanism as on-demand scans) so it does not block a web request. Results are saved to scan history automatically. If a scheduled scan fails — for example because an API key has expired — the failure is logged in the scan history table.

Note: WP-Cron fires on page load. On low-traffic sites, scheduled scans may run slightly later than the configured interval if no page loads occur at the scheduled time. You can use a server-side cron job calling wp-cron.php directly for more reliable scheduling.

The AI Code Triage is an intermediate analysis step that runs automatically during every deep dive scan. It sits between the static code scanner and the main AI audit, acting as a filter to separate genuine risks from false positives before expensive AI analysis is performed.

How It Works

1. Static scan — CloudScale Devtools scans the PHP files of all active plugins for patterns associated with malicious code: eval(), base64-encoded payloads, shell execution functions, dynamic file includes, obfuscated variable names, and suspicious SQL construction. This step is instant and costs nothing.
2. Risk prioritisation — findings are sorted by risk level. The top 10 highest-risk snippets are selected.
3. Context extraction — for each finding, 10 lines of code before and after the flagged line are extracted to give the AI enough context to make an accurate judgement.
4. AI classification — snippets are sent in a single batch to the cheapest available AI model (Claude Haiku or Gemini Flash) with instructions to classify each as one of three verdicts.
5. Main audit filtering — only Confirmed findings are forwarded to the main deep dive audit AI. False positives are silently dropped, reducing noise in the final report.

Verdicts

• Confirmed — the AI assessed the snippet as a genuine security risk in this context.
• False Positive — the code is safe; the pattern matched a legitimate use (e.g. a plugin legitimately using eval() for a templating engine).
• Needs Context — the risk depends on how the function is called or what data it receives; reported as advisory.

All three verdict types are shown in the Code Triage section of the deep scan report. The main AI report only reflects confirmed findings.

Cost

Triage adds a small AI cost per deep scan — typically $0.01–0.03 USD using Claude Haiku or Gemini Flash. If no static findings are detected, the triage step is skipped entirely at zero cost.

The Server Logs tab provides a read-only in-browser viewer for PHP error logs, the WordPress debug log, and web server access/error logs — without needing SSH or a file manager.

Log Sources

The panel auto-detects common log file paths for the most popular server stacks: Apache (access.log, error.log), Nginx, PHP-FPM, the WordPress debug log (wp-content/debug.log), and any custom paths you add. Each source button shows a colour-coded availability status:

• Green — file found and readable
• Amber — file exists but is empty
• Red — file not found or permission denied

PHP Error Log Setup

If PHP is logging to /dev/stderr (the default in many Docker and container environments), errors cannot be read in the browser. The panel shows a setup banner with an Enable button that installs a mu-plugin to redirect PHP errors to wp-content/php-error.log. The mu-plugin loads before all other plugins on every request.

Viewing and Filtering

Click any source button to load its most recent lines. Use the controls to filter what you see:

• Search — live text filter across all visible lines.
• Level — show only lines at or above a severity (emergency, alert, critical, error, warning, notice, info, debug). Lines are colour-coded: red for errors/critical, amber for warnings, blue for notice/info, grey for debug.
• Lines — how many tail lines to fetch from the server (100 to 2000). Changing this setting re-fetches the log.

Auto-Refresh (Tail Mode)

Enable the Tail checkbox to poll the selected log every 30 seconds automatically. Useful for watching a running process or debugging a live issue.

Custom Log Paths

Add any absolute file path readable by the web server user. Common additions include application logs (e.g. /var/www/html/storage/logs/laravel.log), cron output files, or custom PHP-FPM pool logs. Labels are free-text. Custom paths are saved as a WordPress option and persist across plugin updates.

Permissions

System logs (e.g. /var/log/syslog, /var/log/auth.log) are typically owned by root and not readable by www-data. This is intentional OS hardening — the panel shows a clear “permission denied” notice. To expose a system log, add your web server user to the adm group, or use a log-shipping tool to copy entries to a file the web server can read.

The SMTP tab replaces WordPress’s default wp_mail() (which relies on PHP’s mail() function) with authenticated SMTP delivery. This fixes delivery failures on servers where PHP mail is disabled or flagged as spam.

Configuration (Tools → CloudScale Cyber and Devtools → Mail tab):

• SMTP host — your mail server hostname (e.g. smtp.gmail.com, smtp.sendgrid.net, or your hosting provider’s SMTP server).
• Port — typically 587 (STARTTLS) or 465 (SSL).
• Encryption — TLS (recommended), SSL, or None.
• Authentication — username and password. Leave blank if your server allows unauthenticated relay on a local network.
• From name / From email — override the sender displayed to recipients for all outgoing WordPress mail.

Test email: Send a test message to any address directly from the Mail tab to confirm delivery before relying on it for 2FA codes, password resets, and WooCommerce emails.

Email log: The Mail tab maintains a log of sent messages with timestamp, recipient, subject, and delivery status. Useful for diagnosing missed emails. The log can be cleared from the tab.

The Thumbnails tab (Tools → CloudScale Cyber and Devtools → Thumbnails) is a social preview diagnostics suite for ensuring every post shares correctly on Facebook, Twitter/X, LinkedIn, and WhatsApp.

URL Checker

Enter any URL on your site and get a full breakdown of its og:image, og:title, og:description, twitter:card, and related meta tags — exactly as a social crawler would see them. Diagnoses common problems such as missing tags, wrong image dimensions, or images blocked by Cloudflare’s crawler challenge.

Post Scan

Batch-scans all published posts and pages, flagging those that are missing a featured image, have an og:image below platform minimum dimensions, or have no social meta at all. Results are sorted by severity so you can fix the highest-impact issues first.

og:image Generation

For posts missing a suitable social image, the Thumbnails tab can generate platform-optimised variants from your existing featured image:

• Facebook / LinkedIn — 1200 × 630 px
• Twitter/X card — 1200 × 628 px
• WhatsApp — 400 × 400 px square

Generated images are added to the Media Library and attached to the post. You can regenerate them at any time from the Thumbnails tab.

Cloudflare Integration

If your site is behind Cloudflare, social crawlers (Facebook, Twitterbot, LinkedInBot) need to bypass the challenge page to read your og: tags. The Thumbnails tab includes a Cloudflare connection test that verifies crawler user-agents can reach your pages, and a cache-purge button to force Cloudflare to re-fetch your social meta after an update.

Media Library Audit

Scans attached media for images that are too small for any platform’s requirements, images with no alt text, and featured images that exist in the Media Library but are no longer attached to any post.

The Custom 404 tab lets you replace the default WordPress 404 error page with a branded page — and optionally embed one of seven browser mini-games to keep visitors entertained while they find their way back.

404 Page Editor

Set a custom title, message, and redirect link shown on your 404 page. The page inherits your active theme’s header and footer so it matches your site design. Changes are live immediately — no page template file edits required.

Mini-Games

Embed one of seven fully self-contained games on your 404 page. All games run in the browser with no external dependencies:

• Runner — endless side-scroller; tap or press Space to jump.
• Jetpack — vertical jetpack flyer; hold Space to ascend.
• Racer — top-down car racing; arrow keys to steer.
• Miner — tile-based digging game.
• Asteroids — classic space shooter; arrow keys + Space to fire.
• Snake — classic snake; arrow keys.
• Space Invaders — classic fixed-shooter; arrow keys to move, Space to fire. On-screen buttons for mobile.

Leaderboard

Each game maintains a per-browser high score via localStorage. A site-wide leaderboard syncs scores to the server so visitors can compete across sessions and devices.

The SQL Query Tool lets administrators run read-only SELECT queries against the live database from within wp-admin — no phpMyAdmin or SSH required. Results display in a paginated table with column headers and query execution time.

Security model: Access requires manage_options. Every query is validated before execution: block/line comments are stripped, semicolons are rejected, INTO OUTFILE/LOAD_FILE are blocked, and only SELECT, SHOW, DESCRIBE, DESC, and EXPLAIN are permitted.

14 built-in quick queries in four groups: Health & Diagnostics, Content Summary, Bloat & Cleanup, and URL & Migration Helpers.

Keyboard shortcuts: Enter or Ctrl+Enter runs the query. Shift+Enter inserts a newline.

The Performance Monitor is a non-intrusive profiling panel that overlays on every wp-admin screen and frontend page (for logged-in administrators). It collects data in real time without storing anything to the database.

What it tracks:

• Database queries — every query with timing, call-chain trace, and the originating plugin/theme file.
• N+1 detection — highlights patterns where similar queries fire repeatedly in a loop.
• EXPLAIN analysis — click any SELECT query to run EXPLAIN inline and see whether it’s using indexes.
• HTTP requests — tracks wp_remote_get/post calls with URL and response time.
• PHP errors — captures notices, warnings, and fatal errors with file and line number.
• Hook profiler — lists all fired actions and filters with timing.
• Asset inventory — scripts and stylesheets enqueued for the current page load.
• Transient activity — set and delete operations on transients.
• Template hierarchy — the chain of template files WordPress evaluated to render the page.

The panel is enabled by default. You can disable it under Tools → CloudScale Cyber and Devtools → Settings. Data is colour-coded by severity and can be exported as JSON for sharing with developers.

How it works

1. Load from logs — click PHP Errors, WP Debug, or Web Server to fetch the last 200 lines from the corresponding log file. Error-level lines are extracted and listed as clickable rows. Click any row to populate the input.
2. Or paste directly — paste any error message, stack trace, wp-cron failure, SMTP diagnostic, JavaScript console error, or plain-English problem description into the text area.
3. Analyze — click Analyze with AI. The assistant sends the input to Claude or Gemini (whichever API key is configured) with full WordPress and PHP version context.
4. Act on the result — the response is structured into three colour-coded sections: Root Cause, Why It Happens, and How to Fix It. File paths, function names, and code snippets are formatted for readability.

What it can diagnose

• PHP fatal errors, warnings, and notices — including plugin and theme conflicts
• WordPress database errors and table corruption
• WP-Cron failures and missed scheduled events
• SMTP delivery failures and mail configuration errors
• Memory exhaustion and max execution time errors
• REST API and AJAX errors from wp-admin logs
• Web server 500 errors, rewrite rule failures, and permission errors
• JavaScript console errors pasted from the browser DevTools
• Any plain-English description of unexpected behaviour

Requirements

An Anthropic or Gemini API key must be configured under Security Scan → Settings. The assistant uses the same API key and model as the AI Cyber Audit — no separate configuration is needed. Log files must be readable by the web server process; see the Server Logs section for setup instructions.

PHP Error Alerting

The PHP Error Alerting panel (Debug AI tab, bottom section) monitors your PHP error log and WordPress debug log on a 5-minute cron cycle. When new fatal or error lines are detected since the last check, you receive:

• ntfy.sh push notification — delivered to your phone or desktop immediately. Priority is set to urgent for PHP fatals, high for warnings/errors. Uses the same ntfy.sh topic configured under Scheduled Scans.
• Email alert — sent to the site administrator’s registered email address with the error excerpt.

How it works:

1. On each 5-minute tick, the monitor reads only the new bytes appended since the last check (byte-offset tracking) — it never re-reads old content.
2. New content is filtered for lines matching PHP Fatal, PHP Error, PHP Parse, PHP Warning, and PHP Critical patterns.
3. If the count of new error lines meets the configured threshold, an alert fires. Alerts are throttled to one per 15 minutes to prevent flooding during an error storm.
4. On first activation, the current end-of-file position is recorded as the baseline — you will not be alerted for errors that existed before you turned the feature on.

Configuration:

• Enable / Disable — toggle the monitor on or off.
• Alert threshold — minimum number of new error lines in a 5-minute window before an alert fires (default: 1).

Requirements: ntfy.sh notifications require a topic configured under Security Scan → Scheduled Scans → ntfy.sh URL. Email alerts use your configured SMTP settings (or PHP mail as fallback).