54 questions about MySentry, answered plainly

MySentry is a website monitoring service for small businesses and the freelancers and agencies who look after their sites. It watches a website from the outside (is it up, does the page show what it should) and from the inside (application errors, failed emails, scheduled jobs that stopped running), and tells you on Slack or your phone the moment something breaks — then stays quiet while nothing changes.

Owners of shops, booking sites, landing pages and small web apps who cannot watch their site all day, and the freelancers and agencies who manage anywhere from one to fifty client sites. You do not need to be technical to use it; if you are, there is a full reporting API.

No. On WordPress you install a plugin and paste one address; on any other site you add the uptime check in the panel. Alerts are written in plain language — ‘your contact form has failed to send 3 emails in the last 10 minutes’ — and the technical detail (stack traces, request URLs, versions) is kept underneath for whoever fixes it.

Uptime and content checks work with any public URL, whatever it is built with. Browser error reporting and analytics work on any site with a one-line snippet. Deep server-side error reporting comes from the WordPress plugin or, for custom applications, from the reporting API.

Uptime checkers tell you whether the front page answers. They cannot see a checkout that throws an error, a contact form whose emails silently fail, or a nightly backup job that stopped running three weeks ago. MySentry covers uptime and those inside failures in one panel, for one flat price per website.

Developer error trackers are built for engineering teams: priced by the volume of events and written on the assumption that someone reads stack traces every day. MySentry is built for the owner of a small site — a flat price per website with uptime and cron monitoring included, alerts written for humans, and the technical detail one click away when your developer needs it.

Yes. Every new account starts with a free trial with no card required, so you can connect a site and see real checks and alerts before choosing a plan.

MySentry is in early access. Join the waitlist and you will receive an invitation as places open, together with founder pricing that stays locked to your account.

Yes. One account holds many websites — each with its own reporting key, uptime check, cron monitors and analytics — and the Growth and Scale plans cover up to 20 and 50 sites, so the cost per site falls as you add more.

In the European Union. The database runs in Supabase’s EU region (Frankfurt) and the application runs on Vercel in Frankfurt; traffic passes through Cloudflare’s network. Nothing is sold or shared with advertisers.

Every 5 minutes by default. You can set any interval from 1 to 60 minutes per website. Each check waits up to 10 seconds for a response and records the response time, so you also see when the site is slowing down rather than failing outright.

From MySentry’s infrastructure in the EU (Frankfurt). Checks currently run from this single location; to avoid raising an alarm over a momentary network blip, a site is only reported as down after two consecutive failed checks.

A check counts as failed when the site does not answer within 10 seconds, the connection fails, or the final response (after any redirects) is not a success status. One failed check is treated as a blip and ignored; two in a row raise an alert.

Yes. Give each website an expected phrase — a line from your footer, a product name — and MySentry confirms it is present on every check. A page that answers 200 OK but has lost the phrase (a white screen, a hacked or half-deployed page) is reported after two consecutive mismatches, separately from a plain outage.

Domain expiry, yes: the registrable domain of every monitored site is looked up daily through RDAP and the expiry date is shown on the dashboard, amber under 60 days and red under 30. SSL certificate expiry checks are on the roadmap.

A heartbeat is a tiny request your scheduled job sends to MySentry each time it finishes: ‘nightly-backup ran, 1,240 records processed’. If the heartbeats stop — the job crashed, the server rebooted without it, someone changed a password — MySentry notices the silence and alerts you. The first heartbeat registers the monitor automatically; the default silence threshold is 26 hours and can be tuned per job.

That is the failure most monitoring misses: a job that was deployed but never scheduled sends no heartbeat, so a monitor that waits for the first one would wait forever. In MySentry you can register an expected monitor before the job exists; if the first heartbeat has not arrived by the deadline you get a distinct ‘never started’ alert.

PHP fatal errors and uncaught exceptions, JavaScript errors in your visitors’ browsers, failed email sends, failed uptime and content checks, and anything a custom application reports through the API — each with a level (fatal, error, warning, info, debug), the page or request URL, the application version and environment.

Each event is fingerprinted on the server from its context and a normalised message, so the same error is one row with a running count, a first-seen and last-seen time, and the most recent 30 occurrences kept with their stack trace, URL, version and metadata. A thousand repeats of one bug are one line, not a thousand.

An error you marked as resolved that happens again. MySentry reopens it, tags it REGRESSION and alerts you immediately — the fix did not hold, or a deployment undid it.

Email addresses and phone numbers are masked on the server before anything is written to the database — in messages, stack traces, URLs and metadata. The analytics beacon stores no IP addresses and sets no cookies. What else an error contains depends on what your application sends, and the reporting API caps each field.

Errors stay until you resolve, archive or bin them; the bin is emptied automatically after 30 days. Each error keeps its last 30 occurrences. Analytics are stored only as daily totals — page views, unique visitors, time on page and breakdowns by page, country and referrer — never as individual visits.

Yes. The errors table exports every row matching the current filter to CSV (UTF-8 with BOM, so it opens cleanly in Excel), including message, count, first and last seen, version, environment, URL, status, metadata and stack trace.

Email, Slack and push notifications. Email alerts go to every member of the account who keeps them on; Slack is an incoming webhook you paste into each website's settings; push notifications reach your phone or desktop when you install MySentry as an app. SMS and WhatsApp are on the roadmap.

A new error alerts once; its repeats only increase the count. A regression alerts separately. Downtime needs two consecutive failed checks. A silent cron job is reported once a day, not every minute. Failed emails are rolled up: three or more in ten minutes produce one alert about a probable mail outage, not three.

Slack alerts for a website can be muted for 1 hour, 8 hours, 24 hours or until you turn them back on. Push and email keep working while Slack is muted, so a real outage during maintenance still reaches you; each person can switch their own email and push off under Security → Notifications.

Yes. The first successful check after an outage that raised an alert sends a recovery message on the same channels, stating how long the site was down, and the failed-check entries are marked resolved automatically. A single blip that never alerted does not produce a recovery message either.

When three or more email sends fail within ten minutes — a contact form, order confirmations, password resets — MySentry sends one alert about a probable mail outage (provider, DNS, an expired API key). This is the failure that quietly loses enquiries for days: the form says ‘sent’, nothing arrives.

Yes. Install MySentry as an app (on iPhone: open it in Safari, Share, Add to Home Screen; on Android and desktop the browser offers to install it) and switch on notifications in the Security tab. Alerts then arrive as push notifications with an unread badge on the icon.

Create the website in the MySentry panel and copy its reporting URL; install the MySentry Monitor plugin and paste the URL into Settings → MySentry; add your site’s address to the allowed origins in the panel so browser errors and analytics are accepted; press ‘Send test event’. The whole thing takes about two minutes.

PHP fatal errors and uncaught exceptions (the white screen of death), optionally PHP warnings, JavaScript errors in visitors’ browsers, failed wp_mail() sends (contact forms, WooCommerce emails), an hourly WP-Cron heartbeat, and — if you switch it on — privacy-first page analytics. Every event carries the page URL, PHP version and request method.

No. Reports are sent after the page has been served, without waiting for a reply, and repeated identical errors are suppressed locally for 15 minutes before they are sent at all. Browser reporting is capped at 10 errors per visitor session. The plugin does nothing until a reporting URL is configured.

Yes, with any theme or builder. One nuance: a fully cached page is served without running PHP, so PHP errors are captured on the requests that do run it — the admin area, checkout, form submissions, logged-in visitors and cron — while JavaScript errors and analytics are captured on cached pages too.

Yes. The heartbeat is a scheduled WordPress event, so it runs whenever WordPress’s scheduled events run — whether that is triggered by visitors or by a system cron calling wp-cron.php. Set the silence threshold to match your schedule.

WordPress 5.8 or newer and PHP 7.4 or newer. The plugin is GPL-licensed and installed by uploading the zip (downloadable from the WordPress page and from the panel); it is not yet listed in the WordPress.org directory.

By the number of websites you monitor. Every plan includes every feature — uptime, content checks, error tracking, cron heartbeats, analytics, Slack and push alerts — so the only question is how many sites you need. Pay monthly or annually; annual billing costs less than twelve monthly payments. Prices are in GBP and exclude VAT.

One website is one project in MySentry: its own reporting key, uptime check, cron monitors and analytics. Your production and staging copies can report into the same project — events carry an environment field — so staging does not cost a second slot.

Any time. Upgrades take effect immediately so you can add sites straight away; a cancellation runs to the end of the period you have paid for and nothing further is charged.

Prices are shown excluding VAT. Any VAT that applies to you is calculated and shown at checkout before you pay, and your invoices state it separately.

Cards, processed by Stripe. MySentry never sees or stores your card number; invoices and receipts are available from your billing page.

The prices shown during early access stay attached to accounts created in that period. If list prices rise later, founder accounts keep paying what they signed up at for as long as they stay subscribed.

MySentry is designed around GDPR principles: EU hosting, data minimisation (the analytics beacon collects no personal data at all), automatic masking of emails and phone numbers in error reports, bounded retention, and a published list of the processors we use. Our privacy policy states what we collect and why.

MySentry analytics sets no cookies, stores no IP addresses and keeps no identifier in the visitor’s browser. Unique visitors are counted with a hash that changes every day and cannot be reversed. Most sites therefore do not need a consent banner for it — but rules differ by country and by what else your site does, so check your own obligations.

A reporting key is shown exactly once when it is created; only a SHA-256 hash of it is stored, so it cannot be read back even by us. A key can only submit events to its own website — it cannot read anything. You can hold two active keys at a time to rotate without downtime, and revoke one instantly.

Yes — time-based one-time codes (Google Authenticator, 1Password, Authy and similar) and passkeys. Every action taken in the panel — resolving an error, revoking a key, changing an alert setting — is recorded in an audit log.

Members of your account. Access is enforced in the database itself (row-level security), not only in the application, so one customer’s data is invisible to another even in the event of an application bug. Access by MySentry staff is limited to operating the service and helping you on request, and every panel action is logged.

Supabase (database, EU region), Vercel (application hosting, Frankfurt), Cloudflare (network, DDoS protection and the front door to our servers), Stripe (payments) and Resend (transactional email). No advertising or analytics vendors.

Yes. Send a JSON POST with your key as a Bearer token: context, message and optionally stack, level, url, app_version, env and a small metadata object. The API answers 202 when the event is accepted and fingerprints, groups and alerts exactly as it does for WordPress. Libraries are not required — it is one HTTP request.

Add one line at the end of the job: a POST to the heartbeat endpoint with the monitor name and whether it succeeded — a curl command is all it takes. The first heartbeat creates the monitor; the panel then lets you set how long a silence is acceptable.

600 events per minute per reporting key for server-side reporters, 30 per minute per IP address for browser reporters, and a 32 KB request body. Messages are capped at 2,000 characters and stack traces at 8,000; anything longer is truncated, not rejected.

Yes. Add a short snippet that listens for window errors and unhandled promise rejections and posts them to your reporting URL. Browser reports are accepted only from the origins you allow in the panel (CORS), so a copied key cannot be used from another site.

Not yet. Public status pages with uptime history are on the roadmap; today uptime history is shown inside the panel.

Yes. MySentry’s own health endpoint is checked from outside, its internal sweep runs every minute, and the sites of the people who built it run on it every day. A monitoring service that cannot tell you it is down is not one.

Not yet. Errors can be exported to CSV from the panel; a read API is on the roadmap.