Monitor Google Trends on a schedule (and stop fighting 429s)

Description and use

Automated daily monitoring of Google Trends without 429 errors, with detailed per‑term status and cost control.

Problem

Polling Google Trends with pytrends often triggers 429 Too Many Requests, causing cron jobs to write empty files for days.

Outcome

Daily, unattended monitoring of Google Trends data without 429 errors, with clear per‑term status and cost control.

Workflow

• Install apify-client and set APIFY_TOKEN
• Define ACTOR, TASK_NAME, and TRENDS_INPUT with searchTerms, geo, timeRange, and other flags
• Create a task via client.tasks().create() with max_total_charge_usd to cap cost
• Create a schedule via client.schedules().create() with cron_expression 0 7 * * * and is_exclusive=True
• Run the task daily; the Actor uses fresh cookie sessions, exponential backoff with new IPs, and automatic proxy fallback
• Read the latest run output and flag terms that are up against their weekly average or marked as Breakout

Evidence

Google Trends has no official API. The web app calls internal endpoints that are rate‑limited per IP address and per cookie session, and the limits are tight: a handful of quick requests from one IP is often enough to trigger 429s, and datacenter IPs are throttled sooner.

Source

The Actor does what you would end up building yourself: A fresh cookie session per attempt, Exponential backoff with a new IP on every retry, Automatic proxy fallback, A per-term status report in the run's OUTPUT record.

Source

Two settings matter for unattended jobs: max_total_charge_usd on the task caps the cost of every scheduled run, so a typo in the input can't turn into a large bill. is_exclusive=True stops runs from piling up if one is slow.

Source