Àpèjúwe
Know about a crash before your clients do.
When a plugin or theme throws a fatal error, WordPress emails the site owner —
hours later, easily lost in spam, and always in cryptic PHP jargon. CrashAlert
makes the same information instant, readable and actionable:
- Instant alerts to Telegram, email and a custom webhook.
- Culprit attribution — the alert names the plugin, mu-plugin or theme
that owns the failing file (with its version). - Plain-language explanations — “Call to undefined function” becomes
“Plugin versions diverged — roll back the last update”, in English or Russian. - Recovery notice — a green message when the site starts responding again.
- Correlation with updates — “what changed in the 24 h before the crash?”
is answered right in the event card. - Rate-limited — a flood of identical errors produces one alert with a
repeat counter, not a hundred messages. - Failure history with a filterable timeline, kept for your chosen
retention period (default 60 days) and fully removed on uninstall. - Local crash log — CrashAlert stores captured errors in its own table
in YOUR WordPress database (that is what the Event timeline shows), kept
for the retention period you set in the settings (default 60 days) and
fully removed on uninstall. This storage is local, exists regardless of
the optional telemetry, and nothing in it is sent anywhere unless you
enable telemetry — in which case only sanitized daily aggregates leave
your site. - Privacy-friendly by design — alerts go ONLY to the channels you
configure yourself (your own Telegram bot, your siteÌtumọ̀ Yorùbá: ’s email, your own
webhook endpoint). Crash data stays in your own database; the optional,
off-by-default error telemetry (see “External Services”) is the only way
anything reaches the developer, and only if you switch it on. No IPs
stored, stack traces sanitized (relative paths, no call arguments).
CrashAlert never limits your site: the monitor itself is guarded so it can
never be the cause of a white screen, and healthy requests pay a microsecond
overhead.
Looking for more? The optional CrashAlert Pro companion adds a PHP
deprecation radar (warnings that will become fatals in future PHP versions),
unlimited alert channels and a weekly health report: https://yodsira.com/en/product/crashalert/
Why not just rely on the WordPress core email?
Core recovery emails go to the site ownerÌtumọ̀ Yorùbá: ’s address, are easy to miss, contain
a raw stack trace, say nothing about repeats, and never tell you the site is
back. CrashAlert covers exactly those gaps — and delivers to Telegram, where
site owners actually live.
Pro Version
An optional companion plugin adds (one license = one site, 12 months of updates):
- Unlimited alert channels — free covers one of each type (1 Telegram chat,
1 email, 1 webhook), Pro adds as many as you need - PHP deprecation radar — deprecated code you must fix before the next PHP upgrade
- Weekly health report by email
The free version is fully functional on its own and never limited.
Details: https://yodsira.com/product/crashalert/
External Services
CrashAlert sends notifications ONLY to services you configure in its own
settings. The only connection to the developerÌtumọ̀ Yorùbá: ’s own service is the
optional, off-by-default error telemetry described at the end of this
section — nothing is sent until you enable it yourself.
Ìtumọ̀ Yorùbá: — Telegram notifications Ìtumọ̀ Yorùbá: —
* What the service is: Telegram Bot API (api.telegram.org), used to deliver
instant crash alerts to your own bot and chat.
* What data is sent and when: your site hostname, the time of the crash, the
error message (truncated to 200 characters), the file path, the plugin or
theme name and version identified as the culprit, the affected page URL and
a repeat counter — sent only when a fatal error is caught, or when you
press “Send test to Telegram” in the settings.
* Opt-in: the feature is fully disabled until you enter your own bot token
and chat id; you can clear them at any time to switch it off.
* Terms: https://telegram.org/tos
* Privacy: https://telegram.org/privacy
Ìtumọ̀ Yorùbá: — Email notifications Ìtumọ̀ Yorùbá: —
* What the service is: your own siteÌtumọ̀ Yorùbá: ’s email system (wp_mail), used to send
the same alert to the address you choose (site admin by default).
* What data is sent and when: the same alert content as above, only when an
alert fires. Delivery depends on the mail configuration of YOUR site.
Ìtumọ̀ Yorùbá: — Custom webhook Ìtumọ̀ Yorùbá: —
* What the service is: any HTTP endpoint you paste into the plugin settings
(for example, your own Slack/Discord relay or log collector).
* What data is sent and when: a JSON payload with the same alert content,
only when an alert fires or when you press the webhook test button.
* The endpoint is yours; the plugin does not provide, host or proxy this
service.
- Optional, off by default: anonymous error reports. If the admin enables
the checkbox in the plugin settings, a daily batch of sanitized crash
signatures already captured by CrashAlert (message, file name:line, the
culprit plugin or theme, versions, site address) is sent to
https://yodsira.com/api/telemetry so recurring crashes get fixed faster.
Nothing is sent while the checkbox is off.
Why: I am an independent developer, and this is the only way I learn about
bugs I cannot reproduce myself. The free plugin makes no requests at all
until you enable this option; when an error happens, an anonymous
signature is sent to yodsira.com so I can fix it in the next release.
Nothing else ever leaves your site, and you can switch it off at any
moment. Every report is read by a human.
Example of exactly what one report looks like (sanitized):
`message: “Call to a member function get_id() on null” — file: file.php:123 — culprit: plugin other-plugin — versions: plugin 0.1.9, WordPress 6.8, PHP 8.2
That is the whole payload — no content, no user data, no usage tracking.
Disabling telemetry clears any queued reports immediately.
Developer service terms: https://yodsira.com/en/terms/
Privacy policy: https://yodsira.com/en/privacy/
Ìgbéwọlẹ̀
- Upload the plugin folder to
/wp-content/plugins/, or install the zip via
Plugins Add New Upload Plugin. - Activate the plugin.
- Open CrashAlert Settings, paste your Telegram bot token and chat id,
press “Send test” — done. Email alerts to the admin address are on by
default.
There is no easier setup. Alerts are delivered through the channels you
configure: your own Telegram bot (api.telegram.org), your siteÌtumọ̀ Yorùbá: ’s own email
(wp_mail) and, optionally, your own webhook endpoint. The only connection to
the developerÌtumọ̀ Yorùbá: ’s servers is the optional, off-by-default error telemetry
described in “External Services”.
FAQ
-
Will it slow my site down?
-
Healthy requests do not touch the database at all — the monitor checks the
last PHP error in the shutdown phase and exits. Fatal handling is capped
(sanitized stack, queue) and alerts are sent by cron, not during the request. -
WordPress already emails me about fatals. Why this plugin?
-
Speed (Telegram beats email), attribution (named plugin and version), human
explanations, repeat counting, recovery notices and a searchable history.
Core emails stop at “something died, here is a stack”. -
Will I get spammed if a loop throws 500 fatals a minute?
-
No. Identical errors share one signature; one alert goes out per signature
per rate window (default 10 minutes) and repeats are counted (“×500”). -
Does it send my data anywhere?
-
Only to the delivery channels YOU configure in the plugin settings: your own
Telegram bot (requests go from your server to api.telegram.org), your siteÌtumọ̀ Yorùbá: ’s
own email (wp_mail) and, if you enable it, your own webhook URL. The developer
receives nothing. See “External Services” below for the exact data sent. No
IPs are stored, stack traces are sanitized, and uninstall removes everything.
Àwọn àgbéyẹ̀wò
Kò sí àwọn àgbéyẹ̀wò fún plugin yìí.
Àwọn Olùkópa & Olùgbéejáde
“CrashAlert” jẹ́ ètò ìṣàmúlò orísun ṣíṣí sílẹ̀. Àwọn ènìyàn wọ̀nyí ti ṣe ìkópa sí plugin yìí.
Àwọn OlùkópaṢe o nífẹ̀ẹ́ sí ìdàgbàsókè?
Ṣàwárí koodu, ṣàyẹ̀wò ibi ìpamọ́ SVN, tàbí ṣe àgbékalẹ̀ sí àkọsílẹ̀ ìdàgbàsókè nípasẹ̀ RSS.
Àkọsílẹ̀ àwọn àyípadà
0.1.10
- Update: “Send anonymous report to developer” — confirmation dialog,
sending once never enables telemetry; disabling telemetry clears any
queued reports immediately. - Update: telemetry transparency — developer rationale in the settings block
and readme, a sanitized example of exactly one report, and an always-visible
“Send error report now” button (manual, conscious sending).
0.1.9
- New: optional, OFF by default anonymous error telemetry (daily batch of
sanitized signatures to yodsira.com/api/telemetry, disclosed in External
Services; nothing is sent until the admin opts in). - Readme: privacy wording aligned with the optional telemetry
(no absolute “never sends” claims anywhere).
0.1.8
- New: Yodsira Admin UI Standard — design tokens, WCAG-checked palette
(brand mint decor-only), collapsible settings, quiet Pro side card. - New: a one-time contextual notice on the pluginÌtumọ̀ Yorùbá: ’s own pages (day 7, at most
twice ever) inviting a wp.org rating or a support-forum report; fully
dismissible, no tracking.
0.1.7
- New: a “Pro” screen in the admin menu describing the optional CrashAlert
Pro companion (unlimited channels, deprecation radar, weekly health report). - Readme: new Pro Version section listing the concrete companion features.
0.1.6
- New: a CrashAlert section in Tools Site Health Info (version, channels,
rate window, retention, events stored, last incident). - Fix: the admin-configured rate-limit window was ignored — the limiter
always used the default 600 seconds. - Fix: the optional Telegram HTTP proxy field was not saved from the
settings form (wrong field name; the value was also reset on every save). - Fix: the internal version constant lagged behind releases, so asset
cache-busting and the stored version could report an old version.
0.1.5
- Review feedback: the admin menu no longer competes with core items
(position moved to the bottom of the menu). - All translation strings now use the plugin text domain “crashalert”
(previously mixed “yodsira-family” and the default domain). - Renamed the internal components to unique prefixes (WPCRASH_/wpcrash_)
to prevent name collisions with other plugins; removed a stray file from
the package.
0.1.4
- New: optional HTTP proxy for Telegram delivery (hosts that block Telegram).
0.1.3
- Code hardening for the Plugin Check review: table names now use the %i identifier placeholder in every query, settings input is sanitized with map_deep(). Minimum WordPress version raised to 6.2 (introduced in 6.2).
- Removed development artifacts from the package.
- The “site is back online” recovery notice now actually renders after a fatal episode (the recovery was detected but never shown).
0.1.2
- Load the shared Yodsira family components (family status endpoint).
0.1.1
- Documented all external services (Telegram Bot API, email, custom webhook)
in a dedicated “External Services” readme section, with the exact data sent
and links to the service terms and privacy policy. - Corrected privacy wording in Features/FAQ: alerts go only to channels the
site admin configures; the developer receives nothing. - Telegram alert texts are now in English (same as email alerts).
- “Upgrade to Pro” links now point to yodsira.com.
0.1.0
- Initial release: fatal capture, culprit attribution, plain-language
explanations (RU/EN), Telegram/email/webhook alerts, rate limiting,
recovery notices, update correlation, event timeline, retention.
