Inngest-Powered Cron Sync & Job Scheduling
Inngest-Powered Cron Sync & Job Scheduling
Available from: v1.0.8
Sidekick uses Inngest to run durable scheduled background jobs. These jobs handle integrations that don't support webhooks, routine maintenance tasks, and platform health monitoring — all without any configuration required from you.
Why Scheduled Jobs?
Not every service in your digital life can push real-time events. Many APIs only support polling — you have to ask them periodically for new data. Without a reliable scheduler, that means stale data, missed updates, or fragile custom scripts.
Inngest cron jobs solve this at the infrastructure level. Every polling-based integration and every maintenance task runs on a defined schedule, with automatic retries and failure visibility built in.
What Gets Scheduled
Polling-Based Sync
For integrations that cannot deliver webhooks, Sidekick polls the upstream API on a regular cadence and syncs any new data into your assistant's context. This covers services where real-time push is unavailable or unreliable.
- Runs automatically for all affected integrations
- Schedule frequency is tuned per-integration based on typical data freshness requirements
- New data is processed through the same pipeline as webhook-delivered events
Memory Consolidation
Sidekick's AI maintains a persistent memory of your preferences, past actions, and context across all connected services. Over time, this memory grows. Consolidation jobs periodically compact and summarise older memory entries, keeping the assistant's context window efficient and its responses accurate.
- Runs on a recurring schedule in the background
- No action required — memory stays healthy automatically
- Older, lower-signal entries are summarised rather than deleted
Usage Reporting
Scheduled jobs collect usage metrics at regular intervals and submit them to the platform's billing and analytics pipeline. This ensures:
- Accurate, up-to-date usage data for your subscription
- Consistent quota tracking across all connected services
- Reliable input for usage-based billing calculations
Health Checks
Automated health-check jobs run on a cron schedule to proactively monitor the state of your integrations and sync pipelines.
- Detects stalled or degraded integrations before they affect your experience
- Flags unhealthy connectors for automatic remediation or user notification
- Provides operational visibility into the background job system
How It Works
All scheduled jobs are implemented as Inngest functions and registered with the Inngest event bus at startup.
Inngest Scheduler
│
├── [cron] Polling Sync → fetch new data from non-webhook APIs
├── [cron] Memory Consolidation → compact AI memory store
├── [cron] Usage Reporting → submit metrics to billing pipeline
└── [cron] Health Checks → monitor integration & sync health
Key properties of the job system:
| Property | Detail |
|---|---|
| Durability | Inngest retries failed jobs automatically with backoff |
| Observability | Job runs, failures, and retries are visible in the Inngest dashboard |
| Independence | Each job type has its own cron schedule and can fail in isolation |
| No user config | Schedules are managed by the platform — nothing to set up |
Frequently Asked Questions
Do I need to configure anything to enable scheduled sync? No. Scheduled jobs are enabled automatically for all integrations that require them. If an integration you've connected uses polling instead of webhooks, it will be synced on schedule without any additional setup.
How often does polling sync run? Frequency varies by integration and is tuned by the platform team based on each service's API rate limits and typical data freshness needs.
What happens if a job fails? Inngest automatically retries failed jobs. If a job continues to fail after retries, it is flagged for investigation. Persistent failures for your specific integrations may surface as notifications in your Sidekick dashboard.
Does this affect my API rate limits with connected services? Polling is rate-limited to stay within each service's documented limits. The scheduler respects per-service quotas to avoid triggering rate-limit errors.