Deception, inside your own application
Most monitoring products put a decoy on a separate server. That decoy only ever sees people who found that server. A trap on your real site sees people probing your real site — and it removes every piece of per-customer infrastructure, which is why this costs what it costs.
What twenty-three requests become
Six steps, about five minutes
Register your site
You give us one domain. We normalise it — scheme, www and path are stripped — and issue a public key and a secret. The secret is shown once and stored in a form nobody, including us, can read back.
Install the package
One npm install and one line of middleware, mounted before your own routes. It runs inside the application you already have. There is nothing to provision and no DNS to repoint.
Traps go live
Paths no real guest requests — /.env, /wp-admin, /backup.zip — start answering with a plausible 403 instead of a 404. A flat refusal ends the session; the sequence of what they ask for next is the part worth having.
The beacon runs
A small script in your page head reports which host served the page. Copy the page and you copy the beacon, so the copy tells us where it is. We then fetch that host ourselves and look for your markup before calling it a finding.
We correlate
Forty requests over six minutes from one source become one incident with a score, a plain sentence, and every observation behind it. Compression is the product — an alert stream nobody reads has negative value.
You get one email
Severity, what happened, what to do, and a link to the evidence. One alert per incident, enforced by the database rather than remembered by a flag.
What we promise the code will not do
This runs in front of a booking flow. If it throws, hangs, or slows a request it has done more damage than the attacks it detects — so these are structural properties of the package, not policies we intend to follow.
| Fails open | If any path throws, the request continues as though the guard were not installed. |
| Never blocks | No visitor is ever blocked, redirected, challenged or rate-limited by us. |
| Never delays | Reporting is detached from the request. Your visitor never waits on our collector. |
| Reads nothing private | No cookies, sessions, form fields, or request bodies from your real routes. |
| Readable source | Nothing minified or obfuscated. It sits in your node_modules and you can read all of it. |
| Bounded memory | The queue caps at 500 events and drops the oldest. It cannot grow into your process. |
Where this does not help
An attacker who strips our beacon from their copy will not appear on your Copies screen. Most do not, because the copying is automated and the value is in volume — but a careful adversary can, and you should know that before you buy.
We also do not see anything outside your website. If your booking engine runs on a third party’s domain, that is where card data goes and it is outside all of this. The same is true of staff email, which is where the largest actual losses in hospitality happen, and of your property management system.
A monitoring product that implies total coverage is worse than none, because it tells everyone to stop looking.
Ready to install it?
Create an account, register your domain, copy one line of code.