Incident Response & Transparency
This page describes how AdPriva notices problems today, what happens to your data when a part of the system fails, and what anyone can check from outside.
How problems are noticed
- Errors in the API and the anchor worker are reported to an error-tracking service, which alerts the AdPriva team.
- The ingest server, the API, the scoring service and the explorer each have a health endpoint that the hosting platform checks.
- The anchoring pipeline’s progress is public (see below), so a stall is visible to anyone, not only to AdPriva.
What happens when a part fails
| Failure | Effect |
|---|---|
| The ingest server cannot be reached | The tag retries a view event once, 1.5 seconds later. If that also fails, the event is lost and no proof is made. Consent Evidence submissions are retried with backoff and handed to the browser’s sendBeacon when the page closes |
| The scoring service is down | Proofs are still sealed and stored with their public score and verdict (L0 and L1). They have no private L2/L3 result |
| Horizen is unavailable | Proofs are still batched. The batch’s horizen_status shows the problem, and its proofs stay pending |
| The database is unavailable | The ingest server returns an error, and the tag’s single retry applies |
What you can check from outside
GET https://api.adpriva.com/public/stats/summary: proofs sealed and batches anchored in the last 24 hours, and the latest anchor transaction.GET https://api.adpriva.com/public/anchors/recent: the most recent anchored batches, with their Horizen transaction and azkverify_statusfield (NOT_APPLICABLEfor new batches).- The Explorer: any proof, batch or anchor transaction, and its current status.
Personal-data breaches
If a breach affects personal data that AdPriva processes for a publisher, the notification steps for the publisher, as controller, are in Data-Processor Posture §7.
Not in place today
- There is no public status page.
- There is no public archive of incident reports.