ErrorNotifier.com and the ErrorNotifier WordPress SDK

Full report

On this page

Executive summary

ErrorNotifier is best understood as an uptime-first, WordPress-native monitoring product that has added beta browser error tracking, CI test-run ingestion, public status pages, and a .NET logging pipeline around that core. Its public site repeatedly positions uptime monitoring, confirmed incidents, alert routing, and status communication as the main value proposition, while describing error tracking as a lightweight, browser-focused beta rather than a full APM replacement.

The product’s strongest qualities are its clarity of scope and operational honesty. The trust center explicitly distinguishes what is available now from what is planned; the integrations page separates implemented channels from placeholders; and the pricing page is easy to read and relatively inexpensive for uptime monitoring. Public docs also show a coherent architecture: project public keys for browser-side SDK traffic, secret keys for CI and server-side metadata, domain proof via DNS or SDK verification, and signed outbound webhooks.

The main weakness is that the product is not yet feature-complete enough to compete head-to-head with Sentry, Rollbar, or Bugsnag on error observability depth. Public pages and the demo show error grouping, issue triage foundations, releases, artifacts, and feedback, but several adjacent platform capabilities remain “foundation,” “beta,” or “coming soon,” including broader integration coverage and parts of the release/artifact UX. Public docs also leave some ambiguities around supported non-WordPress SDKs, event/volume limits, and the exact commercial packaging of error telemetry.

The uploaded WordPress plugin is materially more capable than the marketing copy alone suggests. In local execution tests of the ZIP, it generated and registered a private diagnostics token, exposed guarded diagnostics and approved-setup REST endpoints, built browser SDK configuration automatically, optionally published a public health-report page, and captured fatal WordPress shutdown errors into a normalized payload sent upstream with secret scrubbing and query-string minimization. Those findings come from direct local analysis and execution of the uploaded ZIP in a mocked WordPress harness rather than from public documentation.

The public demo is genuinely useful for understanding the product model, because it exposes monitors, domains, incidents, alerts, reports, status pages, projects, issues, test runs, releases, artifacts, integrations, audit history, and account/export surfaces. But it is deliberately read-only: actionable controls like manual check, pause/archive, and issue triage redirect to signup/login rather than executing in the demo, so live alert-delivery verification and end-to-end payload inspection are not possible from the public demo alone.

The net assessment is straightforward: ErrorNotifier looks promising as a compact, lower-cost uptime and lightweight frontend incident platform, especially for WordPress-centric teams. It does not yet look mature enough to replace Sentry/Rollbar/Bugsnag for organizations that need deep multi-platform error monitoring, session replay, mature release health, broad integrations, or well-specified compliance and support processes.

What ErrorNotifier is today

Across the public homepage, features pages, docs hub, and pricing page, ErrorNotifier consistently presents itself around five primary capability areas: external uptime checks, incident workflow, alert routing, status pages, and foundational developer telemetry such as browser errors and CI test runs. The homepage describes external HTTP/HTTPS checks, expected status and keyword monitoring, confirmed incidents, email/Slack/webhook alerts, “beta foundation” browser error tracking, and CI test reporting. The docs hub organizes onboarding into monitor setup, worker operations, API integration, JavaScript SDK usage, CI ingestion, .NET logging, and webhook verification.

A concise picture of the public footprint is below.

The product’s public platform model is also narrower than it may first appear. The explicitly documented integrations and SDK paths are:

The most important strategic conclusion from this section is that ErrorNotifier’s public product story is coherent, but its platform surface is broader than its public documentation maturity. As of the reviewed site state, the documentation is strongest for WordPress, browser JavaScript, CI ingestion, and .NET logging.

Plugin and SDK architecture

The public documentation establishes a relatively clean data model. Browser-side traffic uses a public project key in the X-ErrorNotifier-Key header; server-side release, deploy, artifact, and CI/test calls use Authorization: Bearer <secret key>; the public REST namespace is /wp-json/errornotifier/v1; and the major write surfaces are /store, /envelope, /feedback, /releases, /deploys, and /test-runs. Domain ownership is proven either by DNS records or by a running browser SDK using a valid project key on the site’s origin. Error responses use JSON and can return 400, 401, 403, 404, or 429, with 429 representing enforced rate limits on sensitive or project-key ingestion surfaces.

The JavaScript SDK is documented with the fields that matter operationally: projectKey, endpoint, feedbackEndpoint, verificationEndpoint, accountCode, reportBug, showReportBugButton, bugReportTriggerId, basicStats, and pageStatsDetail. Public docs also say page statistics can be configured as domain, path, path_query, url, or off, and that ErrorNotifier warns when the page-stat detail selected in the app differs from the script configuration observed on the site.

The setup wizard makes the architecture more concrete by showing the generated browser snippet and the WordPress plugin install path. It also reveals the product’s public browser endpoints and the fact that the hosted SDK script is served from a WordPress plugin path on ErrorNotifier’s own host.

flowchart LR
    A[Browser page] -->|project public key| B[/store]
    A -->|bug report| C[/feedback]
    A -->|origin proof| D[/sdk-verify]
    E[WordPress plugin] -->|fatal event summary| B
    E -->|diagnostics token registration| F[/wordpress-diagnostics]
    E -->|public health report fetch| G[/public-health-report]
    H[CI pipeline] -->|secret bearer token| I[/test-runs]
    J[Backend .NET app] -->|async batched logs| K[/api/log or self-hosted receiver]
    B --> L[Issue grouping and project views]
    I --> M[Test runs and release context]
    G --> N[Public health report page]

Local ZIP analysis and execution tests

The uploaded ZIP adds important specifics that are not fully spelled out on the public site. I executed the plugin under a mocked WordPress harness and observed the following:

The strongest architectural implication from the ZIP is that the WordPress plugin is not just a thin JavaScript loader. It is acting as a bridge between browser telemetry, local WordPress diagnostics, health-report publishing, approved-domain setup, and fatal shutdown capture. That is a meaningful differentiator for WordPress-centric operators, even if the public product pages understate it.

The .NET side is different. The public .NET logging guide and NuGet page describe an async logging provider rather than a full exception-monitoring platform: it registers with builder.Logging.AddErrorNotifier(), enqueues logs without blocking request threads, batches in the background, retries transient failures with exponential backoff and jitter, and writes failed batches to local fallback files. Default hosted delivery is https://errornotifier.com/api/log, but the endpoint can be overridden either to a WordPress receiver or to a direct ingestion gateway.

That split matters analytically: the browser/WordPress stack is more “productized” than the .NET logging path, while the .NET path is more obviously an ingestion utility. ErrorNotifier’s public docs do not yet show the same end-user error-analysis depth for .NET that Sentry, Rollbar, and Bugsnag publicly showcase.

Demo, onboarding, and live-flow evaluation

The public demo is one of the better parts of the site. It is not a static screenshot gallery; it exposes a read-only workspace with a consistent incident story that ties together a bad deploy, a failed CI run, a latency spike, confirmed uptime failures, routed alerts, and a rollback/recovery. The dashboard, issues view, test runs page, releases page, artifacts page, and audit log all align around that narrative.

The onboarding experience is also thoughtfully layered. There is a short quick start, a public setup wizard intended for “humans and AI agents,” and a demo onboarding page that exposes the actual monitor-creation controls. Between them, a new evaluator can infer the intended setup sequence: create a workspace, verify a domain, add a monitor, connect alerts, optionally install the JavaScript SDK, and schedule workers via WP-CLI or operating-system schedulers.

A notable strength is that the demo exposes enough operational detail to understand the product’s internal logic:

The main demo limitation is that it is strictly observational. Clicking actions like “Check,” “Pause,” “Archive,” or “Triage” does not perform a safe sandboxed action; instead, those controls redirect the user to signup with an explanatory “demo mode is read-only” message. That preserves safety, but it also means a serious evaluator cannot validate alert fan-out, payload contents, or rule behavior without creating a real account.

On latency, the public evidence is partial. The homepage advertises an average response of 142 ms for ErrorNotifier’s own site, while the demo reports 547 ms average response for the demo umbrella workspace and shows per-monitor states/timestamps. Those are useful product metrics, but the public demo does not expose end-to-end alert-delivery latency or live webhook-delivery timings in a way an external evaluator can verify.

From an analyst’s perspective, the onboarding and demo UX are good for comprehension, weaker for proof. The product is easy to understand after 10–15 minutes in the public surfaces, but harder to validate deeply without a real account because the demo stops at the point where the most important trust-building interactions would begin.

Security, privacy, and operations

Security and privacy are handled with unusual candor. The trust center explicitly says the service separates implemented controls from planned or contract-specific controls. Public pages claim SSRF protections against localhost, private IPs, loopback, link-local, reserved, multicast, metadata IPs, and unsafe redirects; HMAC-signed webhooks; role-based organization access; audit logs; and PII redaction that filters tokens, passwords, API keys, authorization headers, card-like values, and email addresses before event storage.

At the same time, the same trust/privacy pages disclose meaningful gaps. Encryption-at-rest claims are deliberately softened: transport security depends on deployed HTTPS configuration, and “formal encryption-at-rest claims need hosting review.” The privacy page says sub-processors, regional data handling, and formal jurisdiction language are still TODO. The trust page similarly says enterprise workflows such as DPA workflows, SAML, SLAs, and private probes require explicit enterprise setup.

That honesty is refreshing, but it has practical consequences. For a buyer doing vendor review, ErrorNotifier is currently easier to trust as a transparent early-stage product than as a fully procurement-ready enterprise vendor. As of the reviewed public materials, it provides a security contact address and describes the operational posture around workers and incident timelines, but it does not yet provide the sub-processor inventory, regional handling commitments, or full compliance posture that a larger regulated buyer would often expect to see on the public trust surface.

Operationally, the product is built around worker execution. The worker docs recommend WP-CLI for production checks, with WP-Cron only as a fallback, and specify separate commands for monitor checks, alert dispatch, domain verification, cleanup, and manual checks. Email digests are described as batching through a configured Mailgun HTTP API, while Slack and webhook channels remain event-based.

The notification model is therefore narrower but fairly disciplined:

The rate-limit story is also incomplete but not absent. The API docs explicitly warn that project-key and public surfaces can return HTTP 429 and should be retried later. The public demo’s project table also shows a 120/min rate value for public browser keys. Beyond that, public pricing/docs do not publish a complete event-ingestion quota matrix for browser telemetry or the .NET logging pipeline.

Pricing and commercial fit

ErrorNotifier’s pricing is one of its most straightforward strengths. The public tiers are:

Commercially, that makes ErrorNotifier very easy to understand if you evaluate it as an uptime/status-page product with some incident-routing and lightweight frontend telemetry. It becomes much harder to benchmark if you evaluate it as an error-monitoring platform, because the public pricing page does not spell out event quotas, burst behavior, replay quotas, source-map/artifact limits, or telemetry retention specifically for the error-tracking side. Public docs do mention 30-day SDK starts/errors/feedback totals for domains and warn that API 429s can happen, but the packaging is not as crisply monetized as the uptime side.

That gap matters because the product has started to straddle two categories. On one hand, it is clearly cheaper and simpler than premium error-observability tools when the buyer mostly needs website uptime and basic alerting. On the other hand, once a buyer starts comparing it to Sentry, Rollbar, or Bugsnag, the missing public quota detail becomes a friction point rather than a feature.

Competitive benchmark

The most honest comparison is not “ErrorNotifier versus one direct competitor,” because ErrorNotifier crosses two adjacent categories: uptime/status monitoring and lightweight error telemetry. Against Sentry, Rollbar, and Bugsnag, it is lighter, cheaper, and more WordPress-shaped. Against Honeybadger, it looks closer in philosophy, because Honeybadger also combines error tracking with uptime/status functionality. Against UptimeRobot, ErrorNotifier offers a more opinionated incident-and-telemetry path, but much less pure uptime scale and market maturity.

The strategic takeaway from the benchmark is simple. If the buyer’s core question is “Which product gives me the deepest modern application error observability?”, ErrorNotifier trails these tools. If the question is “Which product gives me a low-friction operational console for uptime, incidents, status pages, and lightweight browser issue intake, especially around WordPress?”, ErrorNotifier becomes more interesting.

Recommendations and roadmap

The highest-priority improvements are not exotic engineering bets. They are mostly about tightening the contract between what the product already does and what the public surfaces clearly explain.

A practical roadmap, based on those priorities, would look like this:

gantt
    title Suggested ErrorNotifier roadmap
    dateFormat  YYYY-MM-DD
    axisFormat  %b %Y

    section Trust and clarity
    Public support page and linked contact surface     :a1, 2026-06-15, 21d
    Public changelog with product and plugin releases  :a2, 2026-06-15, 30d
    Platform/support matrix                            :a3, 2026-06-22, 21d
    Trust-center sub-processors and regional handling  :a4, 2026-06-22, 45d

    section Product packaging
    Publish error telemetry quotas and limits          :b1, 2026-07-01, 30d
    Clarify plan entitlements for beta error tracking  :b2, 2026-07-01, 21d
    WordPress plugin technical guide                   :b3, 2026-07-08, 30d

    section Demo and UX
    Interactive sandbox for manual check and triage    :c1, 2026-08-01, 45d
    Webhook payload preview and signed-delivery demo   :c2, 2026-08-15, 30d

    section Product depth
    PagerDuty and Microsoft Teams integrations         :d1, 2026-09-01, 75d
    Strengthen releases/artifacts/issues UX            :d2, 2026-09-01, 60d

Open questions and limitations

A few important details remain incomplete or only partially verifiable from public evidence.

First, I did not find a dedicated public Support or Changelog page linked across the reviewed public website. That absence itself is a finding, but it also limits certainty about release cadence, SLA/support expectations, and historical product evolution from the public website alone. The uploaded plugin ZIP does include its own internal changelog, with entries from 3.26.0 through 3.76.0, but that is separate from the public site.

Second, the public demo is read-only, so I could not verify live outbound email, Slack, or webhook deliveries end to end from the demo workspace. I could verify the documented webhook format and the fact that demo actions redirect to signup/login instead of mutating state.

Third, for the WordPress plugin, my strongest findings come from direct local analysis of the uploaded ZIP and execution in a mocked WordPress harness, not a full production WordPress installation with a live ErrorNotifier account. That means the plugin findings are high-confidence about payload shapes, option defaults, and control flow, but not a substitute for verifying a real hosted round-trip in wp-admin against a real workspace.

Fourth, some platform signals in the demo imply wider support than the public docs currently explain. In particular, I saw platform labels such as PHP, Python, and Node in the demo project UI, but I did not find equivalently detailed public installation documentation for them in the reviewed docs set.

Finally, ErrorNotifier’s commercial packaging for the error-tracking side still needs clarification. The uptime/monitoring tiers are explicit, but the public pricing page does not yet fully spell out event quotas, replay availability, artifact/source-map quotas, or telemetry retention by plan in the way mature observability vendors usually do.