Access Monitor
Erfahren Sie in dem Moment, in dem Ihre kritische Seite nicht mehr lädt — von einem echten Android-Telefon, nicht von einem Bot.
- 2 überwachte Ziele
- 6.000 checks / Monat
- 2 GB Nachweis-Speicher
- 20.000 API-Anfragen / Monat
- 60 Tage Aufbewahrung
Das Problem
Traditionelle synthetische Monitore laufen in einem Rechenzentrum: Ihnen entgehen User-Agent-/Geolokalisierungssperren und Challenges (403/CAPTCHA), die nur von einem echten mobilen Gerät aus auftreten.
Für wen es ist
Jedes Unternehmen mit einer kritischen URL/App (Checkout, Login, Landing) muss wissen, ob sie von einem echten Android-Gerät korrekt lädt, nicht von einem Bot oder Headless-Browser.
Was Sie uns senden
| Feld | Format | Validierung |
|---|---|---|
| target | http(s)-URL (oder Android-Paketname für app_launch) | Keine literale IP, keine Steuerzeichen, SSRF-Denylist — bei der Check-Erstellung mit 422 abgelehnt |
| check_type | url_load oder app_launch | Enum, Standard ist url_load |
| frequency_minutes | Ganzzahl, Minuten | Nach unten begrenzt durch die im Plan enthaltenen checks / Ziele |
| timeout_seconds | Ganzzahl, 5-120 | Standard ist 30 |
| failure_threshold | Ganzzahl, 1-10 | Aufeinanderfolgende Fehlschläge, bevor ein Vorfall eröffnet wird |
| alert_email / alert_telegram_chat_id / results_webhook_url | E-Mail / Telegram-Chat-ID / https://-URL | results_webhook_url muss https:// sein; mindestens ein Alarmkanal empfohlen |
| country_code | 2-Buchstaben-Code | Muss einer der im Plan enthaltenen Korridore sein |
Was ausgeführt wird
- Der Worker holt fällige Checks auf echten Android-Geräten ab (nie ein Emulator), bis zur max_concurrency Ihres Plans.
- Jeder Lauf lädt das Ziel und erfasst status, latency_ms, einen Screenshot und signierten Nachweis.
- Ein als kundenseitiger Fehler (Ihre Seite ist down) klassifizierter Lauf zählt trotzdem als erfolgreiche autonome Ausführung, entsprechend dokumentiert.
- Ein Vorfall wird eröffnet, sobald failure_threshold aufeinanderfolgende Fehlschläge erreicht sind.
Was Sie erhalten
- Ein MonitorRun pro check (status, latency_ms, screenshot, evidence)
- Alarme
- Dashboard
- API/webhook je nach Plan
Limits & Kontingente
Loading...
Autonomie
Geplante Checks laufen von Anfang bis Ende unbeaufsichtigt — Abholung, Laden, Nachweis, Alarm. Menschliche Eskalation wird nur ausgelöst, wenn failure_threshold überschritten wird oder der Worker selbst kein Gerät erreichen kann (Infrastruktur-Fehlerklasse).
Compliance
Nachweis
PILOT evidence: 1,503 qualified backtests measured on a real Android phone with a real SIM (99.9% autonomy measured across those runs); network path recorded per run (Wi-Fi today). (Hinweis: Aussagen zu Nachweisen werden auf Englisch veröffentlicht, damit der Wortlaut exakt bleibt.)
Bekannte Einschränkungen
- The screenshot doesn't replace functional business testing — only load is verified.
- AI Visual Change Intelligence (part of Web Assurance) isn't validated yet — not a dependency of Access Monitor's core.
- Runs from a real phone with a real SIM in the served corridor; today the browsing path is the phone's Wi-Fi (the site sees a local fixed-line ISP address, not a mobile-carrier address); the network path is recorded in every signed run.
- (Hinweis: Aussagen zu Nachweisen werden auf Englisch veröffentlicht, damit der Wortlaut exakt bleibt.)
Fragen zu diesem Service
Verwandte Leitfäden
- Was ist der Unterschied zwischen synthetischem Monitoring und Monitoring auf echten Geräten?
- Welche Nachweise braucht eine Cookie-Consent-Prüfung?
- Was ist SIM-basierte Geo-Verifizierung, und wie unterscheidet sie sich von IP- oder GPS-Prüfungen?
- Was deckt die Web-Absicherung auf echten Geräten ab, und wann wird sie benötigt?
- Wie testet man, ob eine App oder eine Website auf Android-Einsteigergeräten funktioniert?