Monitoring for Lovable apps
You described the app, Lovable built it, you published it. Now it has users. Lovable does not tell you when it stops working, and the first person to notice will be a customer.
Where it runs: Lovable publishes to a *.lovable.app address, with a custom domain on top; the data usually lives in Supabase.
Paste your app's address. We propose the checks, you say yes:
We read the page once and propose the checks it needs. Nothing is created until you say so.
Or just check it once, no account:
None of these show up in the editor. All of them show up to your users first.
The *.lovable.app address is Lovable's to keep alive. The domain you bought is yours: it expires, its DNS records get edited, its certificate depends on those records being right. When a record changes, the site is gone and the Lovable editor still looks fine.
The app is a page; the product is the database, the auth and the edge functions on Supabase. A paused project, an exhausted quota or a failed edge function deploy leaves a page that loads and a product that does not. A check that only loads the page will not see it.
Supabase Auth sends confirmation and reset mail through whatever provider was wired in. When the provider's key is rotated or its free tier runs out, sign-ups fail silently: the page says 'check your inbox' and nothing arrives.
Stripe calls your edge function; if that URL stops answering 2xx, Stripe retries for three days and then gives up. You find out when a customer who paid has no access.
OpenAI, Resend, Stripe: a key revoked or a card declined, and the feature that used it returns an error the page swallows.
Lovable apps talk to people by email far more than they look like they do: confirmation links, password resets, receipts, the notification a user asked for. All of it goes out through a provider (Resend, SendGrid, Supabase's own SMTP) on a domain you configured once. Sending breaks in three ways, and none of them shows on the page: the provider stops accepting (key revoked, quota spent, card declined), the domain's SPF or DKIM records change and mail lands in spam, or the edge function that calls the provider fails on deploy. ServerInspector cannot read anyone's inbox. What it can do is run the request that sends, on a schedule, and tell you when it stops answering 2xx; watch the domain the mail comes from; and check the URLs your app depends on as monitors of their own.
Nothing is installed in the app. Monitoring happens from outside, the way your users reach it.
Type your app's address into the free check above. It tells you in twenty seconds whether the site answers, how fast, whether the certificate and domain are in order, and which security headers are missing.
Create a free account and add the same address as a monitor. It is checked every five minutes (every minute on Pro), and you get an email when it stops answering and another when it is back.
Add your custom domain under Domains. Expiry is tracked and you are reminded 30, 14, 7 and 1 day before renewal.
Add your Supabase project URL (the REST endpoint, `/rest/v1/`) as an HTTP monitor with an expected status of 401 or 200: a paused project answers differently, and you will know.
On Pro, create an API test that calls the edge function that sends your mail with a test payload, asserts a 2xx and runs every fifteen minutes. That is the closest thing to knowing your sign-up mail still goes out.
Free plan: 10 monitors or domains, 5-minute checks, commercial use welcome, no card.
