Restart-safe jobs
Jobs persist in PostgreSQL across restarts. Retries are bounded, and failed work has a visible Retry action.
Reliability
Designed to fail without inventing memory.
Crash-conscious writes, durable jobs, transactional source generations, and recoverable projections protect specific transitions—not every failure mode.
Implemented mechanisms
Durability is a chain of explicit transitions.
Small, inspectable state machines replace request-level optimism.
Visible page status
Each page shows whether it is queued, generating, ready, failed, or interrupted. Incomplete work stays visible.
Sources survive disconnection
Losing access to Gmail or Notion stops sync. It never deletes content already imported.
Rebuildable views
Blue-green regeneration builds replacement views before switching readers to them. Pages can be rebuilt from the underlying facts.
Transactions and staged regeneration reduce partial state. They do not cover every storage defect, operator error, provider outage, misconfiguration, or loss outside deployment assumptions.
Crash-safe contributions
Keep the last good source active until the next one is complete.
Replaceable generations keep incomplete re-ingestion from displacing the last good source.
Stage work privately
Extraction and derivation stay staged. Staged or failed work is not active memory and can be cleaned before retry.
Commit one source generation
Activation and supersession commit together. A pre-commit crash leaves the prior successful generation active.
Project from canonical state
Search pages and cards are derived projections. The queue tracks writes, rebuilds, and deletions.
Acknowledge after durable projection
Projection work is acknowledged only after its write or deletion succeeds, leaving unfinished work recoverable.
Operational state
Failures remain visible and retryable by policy.
Jobs expose lifecycle state and bounded diagnostics. Transient failures can retry; permanent policy or content failures stop. Unexpected failures stay generic at the customer boundary.
Retry count, delay, lease duration, provider timeout, retention, and alerting are deployment settings, not guarantees.
Job state
Pending, running, succeeded, and failed states persist with recovery timestamps.
Bounded retries
Retries are selective and bounded; durable does not mean eventual success.
Post-write checks
Post-write checks can leave repair work queued when completion is uncertain.
Current limitations
No reliability adjective replaces an operating boundary.
The first deployments are small, managed, and not a basis for wider service objectives.
No SLA or uptime claim
The service does not currently publish an availability percentage, support-response target, RPO, RTO, or maintenance-window commitment.
Single region
The beta runs in one region with no high-availability replica. There is no automatic regional failover.
Tested paths are bounded
Durable-state, recovery, projection, and deletion paths have focused validation. That does not establish correctness for every input, integration, or compound infrastructure failure.
Operate for recovery
Make incomplete work inspectable, not invisible.
Define retries, human intervention, and the authoritative source before failures occur.
Login / Sign upNow in open beta
Security