Error tracking for people who do not read stack traces — and for those who do

• PHP fatal errors and uncaught exceptions — the white screen of death, from the WordPress plugin or any PHP app.
• JavaScript errors in visitors’ browsers — the button that does nothing on Safari, the checkout script that a theme update broke.
• Failed email sends — contact forms, order confirmations, password resets that report success while nothing arrives.
• Failed uptime and content checks — so outages appear in the same list and on the same chart as application errors.
• Anything your own code reports through the API — with a level (fatal, error, warning, info, debug), the URL, the application version and the environment.

Each event is fingerprinted on the server from its context (for example email.magicLink or wp.php.fatal) and a normalised form of its message. The same error therefore becomes one row — count, first seen, last seen, status — rather than a feed of identical entries, and the fingerprint cannot be spoofed by a misbehaving reporter. Under each row MySentry keeps the most recent 30 occurrences with their stack trace, URL, version and metadata, so the history of a problem is there without the database growing without bound.

Mark an error as resolved and MySentry watches for it by fingerprint. If it comes back — a deployment reverted the fix, a plugin re-enabled itself — the error is reopened, tagged REGRESSION and you are alerted immediately. Errors you choose to ignore stay silent for good; errors you bin are deleted after 30 days.

When a site’s email breaks — an expired API key at the mail provider, a DNS record lost in a migration, a hosting limit — every form still says “Thank you, we’ll be in touch” and nobody is. MySentry counts failed sends reported under the email.* context; three or more within ten minutes produce a single alert about a probable mail outage, with the last context that failed. The WordPress plugin reports every wp_mail() failure automatically.

Open any error to see its level, the full message, the page or request URL, the application version and environment, the metadata the reporter attached (PHP version, request method, browser) and the stack trace. One button copies a complete debug dump to the clipboard for whoever fixes it. The table sorts on every column, filters by status, searches messages, supports bulk actions and exports the current view to CSV.

Email addresses and phone numbers are replaced on the server — in messages, stack traces, URLs and metadata — before anything reaches the database. The reporting API caps every field (2,000 characters for a message, 8,000 for a stack trace, 30 keys of metadata) and rate-limits every key and every IP address, so a runaway loop in your application cannot flood your account.

One HTTP request, no SDK:

POST https://www.mysentry.co.uk/api/ingest/error
Authorization: Bearer <your reporting key>
Content-Type: application/json

{
  "context": "checkout.payment",
  "message": "Stripe returned card_declined for order 1042",
  "level": "error",
  "url": "https://shop.example/checkout",
  "app_version": "2.4.1",
  "env": "production"
}

The full contract — browser reporting with CORS allow-lists, heartbeats, limits — is in the documentation.