Infrastructure Update: Durable Spooling and Browser Identity

TL;DR

This update introduces durable incident spooling to prevent data loss during infrastructure outages, corrects Chrome identity strings in T3/T4 tiers to match real browser emissions, and fixes a critical bug in SLA tracking that falsely reported 100% uptime during monitoring failures.

Improving Browser Fingerprint Accuracy (T3/T4)

Browser fingerprinting has evolved beyond the User-Agent string. Modern bot protection systems now utilize Client Hints (sec-ch-ua) to verify that the browser identity is consistent across all headers.

Previously, our T3 and T4 tiers emitted fabricated Chrome build numbers (e.g., Chrome/{major}.0.{7103+hash}.0) and a hardcoded GREASE brand in the sec-ch-ua header. Real Chrome browsers emit a reduced build string (Chrome/{major}.0.0.0) and use a specific GREASE brand that rotates per major version.

When a vendor detects a non-existent build string, it creates a static signature for all traffic using that version, leading to immediate flagging. We have updated our identity generators to emit authentic strings, ensuring our anti-bot solution remains indistinguishable from organic traffic.

Durable Incident Spooling and Forwarding

Our monitoring infrastructure previously relied on "best-effort" webhooks. If the central incident view or the downstream notification service (e.g., Discord/LLM) experienced an outage, incident detections and recoveries were lost.

We have implemented a durable spool-first producer path. Monitors now write host-local spool files. A dedicated forwarder process then reads these files and pushes them to the central incident API. This ensures that even if the network is down, the state is retained on disk and forwarded once connectivity is restored.

Trusted Runtime Installation

To ensure state retention outside of mutable deploy trees, we introduced the install-trusted-runtime.sh script. This ensures the spool forwarder and its associated state directories are installed in a persistent path, preventing data loss during routine deployments.

SLA Tracker Accuracy Fixes

A critical defect was identified in infra/monitoring/sla-tracker.sh. The script was encoding "no data" as a healthy state. Specifically, if a state file was missing, samples were stale, or there were zero eligible samples, the tracker yielded 100.00% uptime.

In effect, a total monitoring failure looked like perfect reliability. We have updated the logic to report explicit unknown or warming states when coverage is insufficient. This prevents "false positives" in our reliability reporting and ensures that breaches are evaluated based on actual data coverage.

Worker Tier Arbitration and Diagnostics

In the worker layer, we encountered a conflict when a custom configuration auth_tier conflicted with a request's max_tier. The guard in _phase_route_tiers was setting cap diagnostics in an inline dictionary, which was then overwritten by apply_diag_result.

We have persisted these BYOS (Bring Your Own Server) max_tier cap-conflict diagnostics into the final response envelope. This allows developers to see exactly why a request was capped at a specific tier.

For those implementing custom pipelines, you can manage these tiers via our API docs.

# Example of a request specifying a maximum tier to control cost
curl -X POST https://api.alterlab.io/v1/scrape \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com",
    "max_tier": 3
  }'

For users preferring a higher-level abstraction, the Python SDK handles these parameters natively.

import alterlab

client = alterlab.Client("YOUR_API_KEY")

# Requesting a scrape with a tier cap to optimize balance
response = client.scrape(
    url="https://example.com",
    max_tier=3
)
print(response.text)

Summary of Changes

Takeaways

• Browser Identity: T3/T4 now use authentic Chrome build strings and GREASE brands to avoid bot detection.
• Reliability: Durable spooling ensures incident data is never lost during API outages.
• Observability: SLA tracking now correctly identifies "no data" states instead of reporting false 100% uptime.
• Diagnostics: Worker tier conflicts are now visible in the final API response envelope.