Online store
The Stripe checkout stops responding at 02:14 on a Sunday night. You get an email 90 seconds later. You fix it before the first morning purchase is missed.
Uptime monitoring
Email the moment your site goes down.
HTTP/HTTPS ping every minute from an EU region. We alert after 3 failed attempts in a row so you avoid false positives during network blips. No separate tool, no extra invoice, no US transfer.
Get started with Starter Included in Starter
Uptime monitoring
3 monitors active · EU region
1 h6 h24 h7 days30 days
Homepage
https://exempelbutik.se · every 5 min
Checkout API
https://api.exempelbutik.se/checkout · every minute
Up
98.4%
Avg response
142 ms
p95 response
287 ms
Checks
2 002 / 2 016
OKSlowDownNo check
Stripe webhook
https://api.exempelbutik.se/webhook/stripe · every 5 min
Monthly history
Homepage
May 2026
99.7%
April 2026
100%
March 2026
98.9%
Straight from the Spårlös dashboard.
Who uses this?
Three concrete scenarios from real customers. No generic "for marketers" filler.
Agency with multiple clients
5 client sites in the same account. You set one monitor per site and see everything in one view. The client does not see your monitor. They call you when something breaks instead of Google.
Consultant with staging
Monitor both prod and staging. Different intervals (5 min prod, 30 min staging). Avoid staging-down alerts waking you up.
How it works
01
Add a URL
Enter the URL of the site or an endpoint (e.g. /api/health). Choose an interval between 1 min and 1 h. We ping immediately to verify.
02
We ping every minute
HTTP HEAD (falls back to GET if the server does not support HEAD). 30s timeout. We identify ourselves as Sparlos-Uptime/1.0 so you can allow-list us in your WAF.
03
Email on downtime
3 failed attempts in a row gives an email to any address. When the site comes back up you get an email. One notice per outage, not one per failed check.
What you get
- 5 monitors on Starter, 10 on Pro, 100 on Custom
- Intervals from 1 min to 1 h
- HTTP HEAD with GET fallback
- Email on downtime (3 failures in a row)
- Email on recovery
- Inline mini bars on the dashboard for a quick glance
- History per month, last 3 calendar months visible
- Clickable bars for full check detail (mobile friendly)
- Uptime %, p95 response time, average response time per interval
- Pause monitors without losing history
- Custom expected status code (default 200)
What counts as «up»?
We ping your URL with HTTP HEAD. If the server returns the expected status code (default 200) within 30 seconds, it is up. Otherwise it is down.
For endpoints that do not support HEAD (common on CDNs and WordPress vhosts) we automatically fall back to GET. You do not need to configure anything. We note the first HEAD failure, switch to GET for subsequent checks and continue.
Custom status code: change the default 200 to, for example, 301 if you monitor a redirect, or 401 if the endpoint should require auth (then 401 counts as «up» and 200 as «down»).
How alerts work
3 failed attempts in a row gives an email
Filters out brief network blips, dropped packets, momentary DNS problems. On a real outage it means you get the email within 3 to 5 min depending on your interval (3 min on a 1-min monitor, 15 min on a 5-min monitor).
ONE notice per outage
If the site is down for 3 hours you get one «Down» email when we detect the outage and one «Up» email when the next successful check comes in. Not 36 of them. No sleep disruption.
Paused = no check, no alerting
Pause during planned maintenance. The history stays, we just wait to check until you reactivate.
Slack / Discord / Teams / webhook
Email is included. Slack/Discord/Teams/your own webhook is part of the Slack & Webhook alerts add-on (39 kr/mo incl. VAT). Coming soon, sign up to the waitlist in the dashboard.
What is p95 response time?
p95 response time = the response time that 95% of checks are faster than, measured over the selected interval. In other words: only 1 in 20 checks was slower than this number.
We show p95 instead of (or alongside) the average because the average hides occasional spikes. If 19 checks took 100 ms and 1 took 5,000 ms, the average becomes 345 ms. Sounds fine. p95 would have shown 5,000 ms and you would have seen the spike right away. p95 is what visitors actually experience on bad days.
We also show the average response time (to compare with other tools that do not compute p95) and the "Slow" threshold (adaptive: max(1 sec, 2x average) per monitor, so an always-slow endpoint does not spam amber while a fast endpoint flags outliers).
Where we ping from + allow-listing
Right now we check from an EU region. During 2026 we are moving to a Swedish data center and adding a redundant check node. No US nodes, no US sub-processors in the data path.
User-Agent: Sparlos-Uptime/1.0
Methods: HEAD, GET
Timeout: 30 seconds
Frequency: your chosen interval (1 min to 1 h)
In your WAF, server config or Cloudflare rule you can allow-list the User-Agent string above so our checks are never blocked. We do not have fixed IP ranges yet, but the UA is stable and unique.
What you see in the dashboard
Per monitor you get four views that mirror each other:
- Inline mini bars: always the 30 most recent raw checks next to the status pill. Quick glance: is it green? Good. Is it red recently? Click in.
- Expandable detail view: choose a range (1 h / 6 h / 24 h / 7 d / 30 d). You get uptime %, average, p95, number of checks, and a bar chart bucketed by range. Click any bar for the full check detail (time, status code or error message, response time).
- History per month: its own section at the bottom. The last 3 calendar months per monitor as rows. See right away if March had a bad day or if April was clean green. Bucketed per day (one bar = one day) so the months look consistent regardless of interval.
- 7-day summary on the site dashboard: a compact widget on the site detail view so you see uptime without clicking into /uptime first.
Email notifications: what you actually get
Two types of email, both template-rendered, no marketing fluff:
Down
Sent after 3 failed checks in a row. Contains: monitor name, URL, the latest error message (HTTP status or timeout cause), the time of the first failed check, and a link to the monitor in the dashboard.
Back up
Sent on the first successful check after an outage. Contains: total downtime, monitor name, URL, and a link to the monitor. Closes the loop so you know things are back to normal without having to log in.
You own 100% of your data.
No Google, no AdTech, no retargeting pixels, no "business partners" making money off your visitors in the background. Just you and Spårlös.
No third parties watching
We have no business partners in the data path. No ad pixels, no affiliate trackers, no "analytics-on-analytics" services.
We never sell your data
Not to advertisers, not to AI models, not to marketers. Your traffic is not our revenue model. Your subscription is.
All hosted in the EU
ISO 27001-certified EU data center. Schrems II-safe. No US sub-processors. Swedish DPA included.
Frequently asked questions
How often do you check?+
You choose the interval yourself per monitor: 1, 2, 5, 10, 15, 30 or 60 minutes. Our cron runs every minute and picks up all monitors that are «due».
Where do you ping from?+
An EU region. No US nodes. During 2026 we are moving to a Swedish data center.
Do you alert on single failed attempts?+
No. We alert after 3 failed attempts in a row. That filters out brief network blips, dropped packets and momentary DNS problems that would otherwise trigger false alarms.
What counts as «up»?+
An HTTP response with the expected status code (default 200) before the timeout (30s). You can change the expected status code per monitor, e.g. 301 for a redirect you want to monitor, or 401 for an endpoint that should require auth.
Can I see historical outages?+
Yes. Per monitor: 1 h, 6 h, 24 h, 7 d and 30 d on the main view, plus a separate «History per month» section showing the last 3 calendar months. Click any bar for the full check detail.
Why are some bars grey?+
A grey bar = no check was recorded at that time. The most common causes: the monitor was created after that point, our cron dropped a tick (during a server restart or deploy), or the monitor was paused. Real outages show as red. Grey means «we have nothing to say about that point in time».
Do uptime pings count against my monthly pageviews?+
No. Uptime checks go to a separate table and do not affect the pageview quota.
Stop sending data to the US. Start today.
Get the same insights as Google Analytics. Without the banner, without cookies, without the legal headache.