Free website check: uptime, SSL, leaked keys and headers
Paste your address. BugOtter checks what any visitor's browser can see: is it up and fast, when the SSL certificate runs out, API keys in your JavaScript, public .env and .git files, security headers and share previews.
7checks, each with a fix
~20 sfor the whole report
Nothingsaved or stored
Only check sites you own or may test. Read-only, like a browser.
What you get back
A clear verdict first
How many things to fix, split into serious (red) and worth tightening (amber), with status, response time and certificate days up top.
A fix for every finding
Each finding says what it found, where, and what to change. Leaked keys are masked in the report.
Nothing kept
Results are shown once and not saved. Opening the same link runs a fresh check.
What the check looks at
7 checks, each with what it means, why it matters and how to fix it. The report uses the same words.
Is it up?
We open your address the way a browser does, follow up to four redirects, and note the HTTP status, where you end up and how long the server took to start answering.
Why it mattersA 500 or 404 on the homepage means every visitor leaves. A first response over 2 seconds feels broken, even when the page loads in the end.
How to fix itFor errors, open your host's logs for the latest deploy, or roll it back. For slow answers, make the homepage static or cache it, and check for a slow database query or a cold serverless function.
SSL certificate
We read the certificate on port 443: when it expires, who issued it, whether browsers trust its chain and whether it covers your exact domain. We also check that http:// sends people on to https://.
Why it mattersAn expired or mismatched certificate shows a full-page warning in every browser. Certificates are getting shorter, so renewals happen more often and fail more often.
How to fix itLet your host issue and renew the certificate (Vercel, Netlify and Cloudflare do it for free). Under 14 days left usually means auto-renewal is stuck: check that your DNS still points at the host.
Secret keys in your JavaScript
We read the page and up to 20 of its own script files, looking for OpenAI, Anthropic, Stripe secret, AWS, GitHub and Slack keys, private keys and Supabase service-role keys. Anything found is masked in the report.
Why it mattersEverything in your JavaScript is public. Bots scan bundles for keys, and a leaked OpenAI or Stripe key can cost real money within hours.
How to fix itRevoke the key first, then make the call from a server route. Environment variables starting with NEXT_PUBLIC_, VITE_ or PUBLIC_ are built into the browser bundle, so never put a secret in one.
Database rules (Supabase, Firebase)
If your site ships a Supabase URL and its public key, we ask Supabase which tables that key can see and count the rows it can read. We never download a row. For Firebase we check whether the Realtime Database answers a public read.
Why it mattersThe public key is meant to be public, but only when row-level security is on. Without it, anyone can read your users table with the key from your own site.
How to fix itTurn on Row Level Security for every table and add policies, for example "users can only read their own rows". In Firebase, require auth in your database rules.
Exposed files
We ask for /.env, /.env.local and /.git/config, and only count them as public when the answer really looks like that file (not your 404 page).
Why it mattersA public .env hands out every secret at once. A public .git folder lets anyone download your source code and its history.
How to fix itBlock dotfiles on your host or server, make sure your build output folder is what gets deployed, then rotate every secret that was in the file.
Security headers
We look for Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff and clickjacking protection (X-Frame-Options or CSP frame-ancestors).
Why it mattersThey're cheap insurance. HSTS keeps browsers on HTTPS, CSP limits where scripts can come from, and frame protection stops other sites from wrapping yours to trick clicks.
How to fix itAdd them in your framework or host config (Next.js headers(), vercel.json, Netlify _headers, Cloudflare rules). Start CSP in report-only mode so it can't break your site.
Share preview
We check for og:title and og:image tags in the page.
Why it mattersWithout them, a link to your site on X, Slack, LinkedIn or iMessage is a bare URL. With them, it's a card people click.
How to fix itAdd og:title, og:description and og:image (1200×630 works everywhere) to the page head. Most frameworks have a metadata API for it.
What it doesn't do
The check is a quick look from the outside, not a penetration test. Here's where it stops.
One page, one moment. It checks the address you give it, right now, from one place. It doesn't crawl your site or log in.
No attack traffic. It doesn't try passwords, inject anything, scan ports or test your server software for known holes.
Known key formats only. A key in an unusual format, or in a script that only loads after a click, won't show up.
Certificates expire on their own schedule. The CA/Browser Forum's ballot SC-081 cut the longest allowed certificate life to 200 days from March 15, 2026, falling to 100 days in 2027 and 47 days in 2029. A clean result today says little about next month.
Check once here, or every minute in BugOtter
This page answers “is it fine right now?”. BugOtter answers “tell me when it isn't”.
123
1
Every day at a glance. Amber means a short blip that day.
2
Response time every minute on Builder and Pro, every 5 minutes on Starter.
3
3 regions (US East, Europe, US West). Down only when two agree and a retry confirms.
An app is only called down when at least two regions agree and a retry confirms it, so one flaky network path doesn't wake you up.
BugOtter also reads the SSL certificate every 6 hours and warns you when fewer than 14 days are left. It checks the domain's registration once a day, warning 30 days ahead.
Alerts go to email, Telegram, Slack, Discord or push, and each app can have a public status page. See pricing for what each plan includes.
Questions
Is it safe to scan my site?
Yes. The check only makes ordinary read requests, the same ones a browser makes: the page, up to 20 of its scripts, three file addresses, one plain http:// request and a TLS handshake. On a Supabase site it adds up to a dozen HEAD requests that count rows without reading them. It never submits forms, logs in or writes anything. It identifies itself as BugOtterCheck in the user agent.
Do you store results?
No. Results are shown once and not saved; opening the same link runs a fresh check. To stop the tool being used to hammer sites, we count checks per IP address (10 an hour) in memory for one hour, and nothing about the check is written to a database. Like any website, our host's request logs can briefly include the page address.
Can I scan a site I don't own?
Only scan sites you own or have permission to test. The check reads public pages, but the database step asks a site's Supabase or Firebase what its public key can read, and that's for the owner to decide. If you find a leak on someone else's site, tell them privately.
Does it find every leaked key?
No. It looks for well-known key formats in the page and in up to 20 scripts served from your own domain. Scripts loaded later (after a click, or on another page) and keys in formats we don't know aren't covered. A clean result means none of the common, costly leaks are visible on your homepage.
Why does my site show HTTP 403?
Usually bot protection: Cloudflare, Vercel's firewall or password-protected preview deployments block automated visitors like ours. If real visitors get through, it's fine. If you want BugOtter to monitor the site, allow its user agent in your firewall.
Why is the response time different from what I see?
It's a single measurement from our server, including the DNS lookup, connection, TLS handshake and any redirects, with nothing cached. Your browser may reuse a connection or a cached page. For a fair picture, look at response times over days, from several places.
How often should I run it?
After any deploy that changes your build, environment variables or hosting config, and whenever you add a new API. For the things that change on their own, like uptime, response time and certificate expiry, a monitor that checks for you is less work.
Know before your visitors do.
14 days of everything, no card needed. Plans from $10 a month, billed yearly.
