- The whole "Maximum cost per run" you set is now spent on trending searches. A capped run used to hold back about a tenth of your cap as a cushion against platform usage — but your cap pays for the trending searches and nothing else, so that tenth was cap you had asked to spend and did not get: a cap worth eleven searches planned ten. A run now plans every trending search its cap can pay for, and still ends on its own line naming your cap and what was left, never on a run the platform cuts short. Nothing about the price, the charged event, the input form or any output column changed.
- The price is now on the first screen of this page, in the opening line. It sat about 1,800 characters down, below the sample block and the input-form picture. The opening line now reads as what you came for and what it costs: Google Trends trending searches, live, from $0.50 per 1,000 trending searches — with the no-start-fee and never-charged-for-an-empty-pull promise kept directly under it, word for word. This build changes nothing about the run: no input field, output column, charged event or price moved.
- The shelf note about a sibling actor's lookup fee now reads as a live charge, not a coming one. Nothing on this actor moved: no price, input field, output column or charged event changed, and a run costs what it cost yesterday. What changed is a neighbour this page points at — the keyword-volume actor's fresh-lookup fee of $0.19 was announced ahead of time and is now charging, so the sentence that said it was coming says it is here. A run there answered from its 30-day cache still adds nothing, and the same block's note about the three actors that add a small delivery-conditional fee is stated in the present tense for the same reason.
- The page now tells you, on its first screen, whether a schedule is worth paying for. Whether to run this once or on a cron is the first question a trending feed raises, and the answer — measured over scheduled hourly polls — was buried most of the way down the page. It now sits with the price, before you spend anything: the US and India lists turn over 10 of 10 and 8–10 of 10 trends an hour, Great Britain 2–5 of 10, so an hourly schedule sees genuinely new trends every time and a daily one misses most of them, and because nothing is charged for starting a run a schedule pays exactly the same per trend as a one-off. The same figures were already further down the page and are unchanged. No price, input field, output column or charged event moved.
- The page now shows a full delivered row, not just a few columns of one. The Output section carried a screenshot and a trimmed table; it now also ends with a complete row from a live US run — the traffic floor, the news behind the trend, the explore link and the charge record — so you can see the exact shape before you spend anything. No price, no input, no output column and no charged event changed.
- The input form now opens with the call that works, what one trend costs and what is never charged — the screen an AI agent reads. An AI agent shopping the store never reads this page: it reads the input form's own description, and that description used to describe the run to a human. It now opens with a ready-to-send input and the multi-country shape beside it, says which field is required and that every other one can be left out, gives the per-trend price on the Apify free plan and on paid plans with the per-1,000 arithmetic, repeats that nothing is charged for starting a run so the actor can be polled freely, lists what is never charged — an uncovered country, an empty pull, a refused fetch, anything filtered out by the traffic floor — names the run option that caps the bill and the ceiling Google itself sets at 10 trends a country, and points a full timeline or a rising-query question at the right sibling actor. Country leads with the value shape and its example instead of the console instruction, which now comes last. Nothing else moved: no input field, output column, event or price changed, and the console form behaves exactly as before.
- An aborted or migrated run now leaves its receipt from the first moment of the run, instead of only after start-up finishes. The record that says how a run ended was only put in place once the run had finished starting up — reading your input, opening its stores, working out what a previous attempt had already delivered and charged. A run stopped inside that window ended with nothing written about it at all, which mattered most on a re-started run, where the thing not written about was the earlier attempt's work. It is now in place from the run's first moment. Nothing else moved: no input field, output column, event or price changed, and a run that reaches its work behaves exactly as before.
- This actor has a new title on the store: Google Trends Trending Now Scraper — Live Trending Searches. Same actor, same id, same URL, same input, same output, same price — only the words on the listing changed, so nothing you have saved, scheduled or wired into an integration needs touching. The title now carries the phrase buyers actually search for, which is the only reason it moved.
- A limit outside this actor's range no longer refuses to start the run. "Max trends per country", "Max trends for the whole run" and "Max run seconds" each had their range enforced by the input form itself, so
maxItems: 5000, or an AI agent guessing maxRunSeconds: 10, did not start a run at all: you got a validation error, no rows, no status line and nothing to look at. The ranges are unchanged — 10 trends per country because that is all Google publishes, 2,000 trends for a run, and a run window between 15 seconds and an hour. What changed is what an ask outside one of them does: the run now starts, uses the nearest end of the range, writes one uncharged row saying what you asked for and what bound it, and names it on the run's status line.
- "Minimum traffic" now has no ceiling at all. It used to refuse anything above 10,000,000. It is your own filter and a higher floor only removes rows, so any value is accepted as you typed it — a floor nothing clears still comes back as the uncharged row it always did. Your defaults and prefills are unchanged, and nothing about what a run costs moved.
- Nothing else moved: no input field, output column, event or price changed.
- The README opens with the one-click MCP pin instead of burying it at the bottom. The pin link, the actor id, the one input field you have to set with a real example, and how to cap what a run may spend now sit in the first screen, so an agent reading this page finds them. The list of our other actors at the foot of the page also names a renamed one by its current title again. The listing title, the description and the price above them are exactly as they were.
- A maintenance build otherwise: nothing about your runs changes. The private run-report this actor writes for our own support — counts only, never anything you typed — now also records what one charged event cost on the run, beside the count of them. Only we read that record.
- Charges are unchanged. Only delivered trends are charged, there is no result fee, and no uncharged row became a charged one.
- A maintenance build: nothing about your runs changes. The private run-report this actor writes for our own support — counts only, never anything you typed — gained room for four figures it does not fill in yet: how many targets a run was given, how long it waited on a blocked source, how many of those waits recovered, and a reason code for an item our own size limit refused. The build carries the shared contract so a later one can report them; on this actor every one of them is left blank, and nothing a run does or costs is different.
- Charges are unchanged. Only delivered trends are charged, there is no result fee, and no uncharged row became a charged one.
- A pause on a refused country is now sized, not just approved. The run used to decide only whether it could afford one more pause; it now also decides how long that pause may be, from what the countries still open are worth. A one-country run pauses briefly; a wide run pauses longer; a run that has delivered nothing keeps one short retry either way.
- Charges are unchanged. None of these rows was ever charged and none is charged now; only delivered trends are charged, and there is no result fee.
- An uncharged row no longer tells you Google rate-limited us when we never saw a rate limit. When a country could not be delivered for a temporary reason, the row said "Google rate-limited or dropped the request" — whatever had actually happened. That one sentence covered a server error at Google, a connection that died, a page that was not the feed at all, and our own reader failing on an answer Google sent perfectly well, so on the last of those it blamed Google for a bug of ours. A row now names a rate limit only when Google itself sent one, names a dropped connection only when the connection really dropped, and says plainly that the answer was ours to read when our reader is what broke. Everything else says only what we saw: that the trending searches were not served on this run, that it is not a verdict about the data, and to re-run.
- The same rule now applies to the sentence a row adds after the run has waited. A run that pauses and tries a country again used to add "it was still refused" to every such row, including the one whose whole wording exists to avoid naming a cause. It now matches what was actually seen — still rate-limited, the connection dropped again, the answer still unreadable, or simply that it still did not answer.
- The run log line about a wait says the same thing. "Google refused 2 countries" is now "Google did not serve 2 countries", because a country reaches that count by elimination, not by a refusal anyone observed.
- Charges are unchanged. None of these rows was ever charged and none is charged now; only delivered trends are charged, and there is no result fee.
- A run with a very short time limit now actually fetches. The lowest Max run seconds the form accepts is 15, and a run set that low used to finish successfully having collected nothing: the actor held back more time for writing your rows and the end-of-run summary than the whole run had, so it never opened a single connection — the run looked correct while doing nothing. What it holds back is now a share of the limit you set — a quarter of it, never under five seconds — and the connection is given whatever is left after that, so a short run makes a real attempt and still writes your rows and its summary. Every limit of forty seconds or more behaves exactly as it did before, and the lowest limit the form accepts is unchanged, so a task you have already saved keeps working.
- A refinement to the run's own anonymous report to us rides this build. It only affects how a run explains its own leftovers to us — counts and reason codes, never your input or your rows. Your rows, your columns, your receipt row and your bill are exactly as they were.
- Charges are unchanged. Only delivered trends are charged; a run that delivers nothing charges nothing, and there is no result fee.
- The run's own record now counts the trend rows your limits left uncollected. When your Max items cap filled, your maximum cost per run was reached, or the run's clock ended the walk, the countries still ahead of it — and the rows inside a country it had already read — were simply absent from the report this run writes back to us: a run that asked for thirty rows and delivered seven closed its books with twenty-three named by nothing at all. Each is now counted under the limit that stopped it, so a run that stops short of what you asked for is visible to us without you having to report it.
- A run that stopped at your item cap now also records whether that cap really filled. It is one true-or-false fact about the run, never the number you typed, and it lets us see a run that claimed your cap stopped it while it had in fact delivered fewer rows than you allowed.
- Nothing you can see changed. Your rows, your columns, your receipt row and your bill are exactly as they were — only delivered rows are charged, and a row that was not delivered is not charged.
- Every trend you asked for is now accounted for, one by one, in the run's own report to us. Each run sends us a small anonymous report — counts and reason codes only, never your input or your rows — and it now balances: the trends your settings asked for equal the trends delivered plus the trends named by a reason, and any remainder is a limit the run itself names. Before, a country Google rejected, or a traffic floor that kept nothing, was written on its own uncharged row but counted nowhere in that report, so a run for two countries where Google rejected one read as "asked 20, delivered 10" with nothing to say where the other ten went. Now each of those ten is named: a rejected country code and an unreadable country are counted as input errors under the field you typed them in, a country that published trends none of which reached your traffic floor is counted as trends your own floor removed, and a country that published nothing is counted as empty — all in trends, the unit you are charged in.
- "How much you asked for" is now every country you named, times your per-country limit — and a whole-run limit that fills is reported as the limit that stopped the run, not as a smaller ask. A country the actor could not read still counts as asked for (and its trends are named as an input error); a run your row cap stopped reports the cap. Nothing about what you receive or what you are charged changes.
- A country code Google does not cover is now named on the end-of-run line, beside the count of countries that returned nothing, and such a run asks you to open an issue if it looks wrong. It used to be visible only on its uncharged row.
- Charges are unchanged. A rejected country, a country your floor emptied, an empty feed and a refused feed are all uncharged, and only delivered trends are charged.
- A run that waits now always keeps room to finish and report. When Google refuses a country, the run can pause and work that country again — but the check that decided whether a pause was affordable kept back only half a minute for the second set of tries, while a full set here takes closer to two minutes. On a run whose time limit fell in a narrow band (roughly six to seven minutes, including a shorter limit you set yourself), the pause was allowed and the tries after it then ran into the time the run keeps back for writing your rows and the end-of-run summary. The check now keeps back a whole set of tries, measured from this actor's own connection settings, so a pause is taken only when the run can finish the work the pause was for. A run with room to wait waits exactly as it did before; a run without it answers straight away instead of running short.
- Charges are unchanged. Waiting is uncharged, a refused country is uncharged, and only delivered trends are charged.
- The run's own report of how much you asked for is now counted in trends, not in countries. Every run sends us a small anonymous report — counts and reason codes only, never your input or your rows — and the "asked for" number in it was the number of countries while the "delivered" number was the number of trends. A run for one country that delivered three trends reported an ask of one against a delivery of three, which reads as a run that over-delivered rather than one that did exactly what it was asked. It is now the trends your own settings can yield: your per-country limit across the countries you named, capped by your whole-run limit. Nothing about what you receive or what you are charged changes.
- The end-of-run line no longer says a country "returned nothing" when the run simply never reached it. If your whole-run limit filled on the first country, the countries after it were never asked — but the line counted them as countries that answered with nothing. It now counts only countries that really did answer with nothing; a country that was never reached is covered by the limit the line already names.
- A run you start with nothing set can now wait out a refusal too. Pressing Start on the untouched form runs a real sample — the top trending searches for the US — and that sample had its own three-minute limit, which was too short to wait for anything. If Google refused the feed, the sample tried for about half a minute and handed back the uncharged "please re-run" row while the rate limit that caused it was still lifting. The sample's own limit is now eight minutes: enough to hold one full set of tries, one wait of up to three minutes, a second full set of tries, and time kept back to write the row and the summary. A sample Google answers straight away is exactly as fast as it always was — the limit is a ceiling, never a wait — and a lower limit you set yourself still binds.
- A run with one country to fetch may now spend the rest of its time being patient. The waiting budget used to be a flat half of the time left, whatever you asked for. It is now sized to the ask: one country — the commonest thing this actor is asked for, and what a bare Start is — has nothing queued behind it, so it may use what is left. Two or more countries keep half back for the ones still to fetch, exactly as before, so no run is made less patient than it was.
- Charges are unchanged. Waiting is uncharged, a refused country is uncharged, and only delivered trends are charged. A bare Start still delivers at most five trends and still charges only for the trends it delivers.
- What still never waits: a country code Google rejects, a feed that really is empty, a traffic floor or news filter that kept nothing, and your own row, time and cost limits. Those are answers, and a wait cannot change them.
- A country Google refuses is now waited out inside your own time budget, instead of being handed straight back for a re-run. Until now the run tried a refused country three times over about half a minute and shipped its uncharged "please re-run" row with almost the whole window unspent — on a rate limit that lifts in minutes, the same minutes the row asked you to wait. Now, while the run still holds real time and the trends still to collect can pay for the idle minutes, it waits a minute and a half to three and works that country again on fresh connections. A country that answers after the wait delivers exactly as before, charged per trend. A country still refused ships the same honest uncharged row, which now says what was tried: how long the run waited and how many passes it made.
- Countries are worked in the order you sent them, so the first refused country is the one that waits — and because this feed refuses a connection rather than a country, the minutes it waits are minutes every country after it also gains. A run's waiting is capped in total, not per country.
- What never waits: a country code Google rejects, a feed that really is empty, a traffic floor or news filter that kept nothing, and the run's own row, time and cost limits — those are answers, and a wait cannot change them.
- "Max run seconds" now defaults to 600 instead of 120. A 120-second default could never hold a wait, whatever you set elsewhere; 600 is the same window this actor already runs inside, so a run you set no limit for now has room for one wait after a refusal. A run Google answers straight away is exactly as fast as before, and a lower limit you set yourself still binds.
- Charges are unchanged: waiting is uncharged, a refused country is uncharged, and only delivered trends are charged.
- The summary row carries what the waits bought — passes, seconds waited, how many refusals lifted — and the run log says it in one line.
- Set a limit but no country and you now get the sample, not a note asking for a country. Pressing Start with nothing at all always ran a real 5-row US sample. Changing one thing first — a lower "Max trends per country", a traffic floor, the news toggle — used to cancel it: you received one uncharged row asking for a country and no trends at all. Narrowing a setting made the run worse than touching nothing, which is backwards. Now the sample runs under whatever you set: what you set is kept, what you did not set takes the sample's own value, and a limit larger than the sample's own is capped at it, so a sample can never grow into a bill you did not ask for. A limit smaller than the sample's still binds — set 2 and you get 2.
- One extra uncharged row on those runs names the settings it used, in the same words the form uses, and says how to run your own country. It is not a miss and nothing is charged for it; the trends themselves are charged exactly as any run.
- A field name this actor does not recognise, and a country box you set but left empty, still get the single uncharged row asking for a country. Both are you asking for something a US sample would answer wrongly.
{} is untouched. The daily health check and a bare Start deliver exactly what they delivered before, at the same price, with no extra row.
- The run's own report to us now carries the size of your ask — the countries you set, counted before any limit applies. On the commonest input this actor takes, a single country in "Country", it could not read an ask at all, so a run that turned everything away looked like a run with nothing to do and never reached us. A country you asked for that came back empty, or that the row cap never reached, still counts as asked for; a country we could not read at all does not, because it was never asked for.
- A country the run cannot read is reported under the field you typed it in — "Country" or "Countries", the field name only and never the value. The uncharged row in your dataset now carries that field too, so a run with both boxes filled says which one to fix without you re-reading the sentence; rows that are not about an input mistake are unchanged and do not grow a column. A check that is too strict now reaches us as one thing to fix instead of looking like many unrelated typos. A field nobody has declared stays in the general count rather than disappearing from both.
- Nothing this build changes affects what is delivered or charged. One unreadable country still refuses only itself; every other country you asked for still runs, exactly as before.
- A shared piece of Google Trends reading code was refreshed on 4 September and is carried in this build, unused. The change teaches that code to tell a chart Google answered with nothing in it apart from a request Google never answered at all. This actor reads only the trending-searches feed and never calls either of the two functions the change touches, so it is inert here: no behaviour, no row and no charge differs because of it. It is written down rather than left silent so the contents of this build are on the record.
- Wording: two past entries on this page described rows as "free". They are uncharged — you still spend platform time on any run — so they now say so. No fact, number or version heading changed.
- A country code we could not read is now reported back to us by the field it came from — "Country" or "Countries", the field name only and never what you typed. Input mistakes were reaching your rows but not our own run reports, so a check that is too strict looked like many unrelated typos.
- This build also ships the shared Google Trends client the sibling Trends actor already runs — the same request and parsing rails on both. Nothing changes in what you receive.
- A run that stops before it starts now reports its outcome too — a run refused for its memory setting now reaches us the same way every other run does: counts and reason codes only, never your input or your rows.
- Every run now reports its own outcome to us — counts and reason codes only, never your input or your rows — so a run that goes wrong reaches us even when nobody shares it.
- Run status lines fit the run page again; sample-run wording shortened.
A run that resumes after a platform restart now recognises every row it already delivered, so nothing is delivered or charged twice.
Apify occasionally moves a running actor to another server. When that happens, the run re-reads its own dataset to remember what it already delivered. Until now it trusted the dataset's row count, which can lag for a moment after a restart; a lagging count could make the run start over and charge again for rows you already had, stop before the end, or stop the run outright as a precaution. The run now checks for real rows instead of trusting the count, and reads to the end whatever the count says. Rows, prices, charges and the status line on a normal run are exactly as before.
- A run that filled the row cap you set is no longer treated as a run that went wrong. The Issues-tab line now appears only when something actually did.
- One support promise on this page — the reply time is stated once, in the Feedback & support section, instead of twice.
- A run that ends with a problem now says where to reach us. A miss, an input error, an early stop or a failed run closes by pointing at the Issues tab and naming the reply time; a fully delivered run is left alone.
- One support promise across this page — issues are answered in a couple of hours, always within a day.
The two screenshots on this page now load from Apify's own storage instead of an outside website, and the free templates section no longer carries an outside link — the workflow templates are still free, and our Apify profile points to them. Nothing about what this actor delivers or charges changed.
The suite blocks at the bottom of this page now state the three delivery-conditional fees that start 16 September 2026 on sibling actors — keyword volume's fresh lookup, profile posts' profile lookup, and Google Jobs' search fee. This page also now says "nothing charged for starting a run" wherever it used to say "no start fee" — the same promise, in the words the whole shelf uses. Nothing changes on this actor: same price, same events, same rows.
See the real thing before you run it.
- Two screenshots of an actual run now sit on this page: the input form exactly as it looks when you open the actor, and the dataset table it fills — the US top 5 trending searches with the traffic floor, when each trend started, the news count and the explore link.
- One link pins this actor in any AI agent (Claude, Cursor, or any MCP client) — it is at the bottom of the page.
- The input form's note about starting with nothing set now matches what that run does. It fetches a real 5-row US sample, charged like any run; it stopped returning uncharged placeholder rows in the previous build, and only the wording lagged behind.
- The links to the rest of the shelf carry each actor's current name.
Start with the default form and get real trending searches instead of placeholder rows.
- A bare Start now runs a 5-row sample. Click Start with nothing set (or send an empty input from the API) and the run pulls the top five trending searches for the US and returns their full rows, charged like any other rows. The placeholder "sample rows" are gone; what you see is what a real run returns.
- The sample stays small and quick by design: one country, five rows, and a three-minute window. On a bad minute you get one uncharged row saying the feed was not served (re-run in a minute), never an empty dataset.
- The status line says when a run was the sample and how to run your own countries.
- Nothing else changed: any input with a country in it behaves exactly as before, and a mistyped field still gets a row naming the field instead of a sample.
Sending null for a setting you do not want now means "use the default", instead of stopping the run before it starts.
- An optional setting sent as
null now takes its default. Agents, n8n templates and MCP callers routinely fill every field in a template and send null for the ones they have no value for. Until now Apify refused those runs before the container even started — you got a validation error, no run and no rows, and the fix was to know that you had to leave the key out entirely. Every optional setting on this actor now accepts null and reads it as "use the default", which is exactly what omitting it does. geo is the one required setting and still needs a real value.
- A
null limit means the documented default, never the smallest allowed value. Sending null for "Max trends per country", "Minimum traffic", "Max trends for the whole run" or "Max run seconds" gives you 10, 0, 100 and 120 — not 1. includeNews sent as null stays on.
- The input form and README no longer tell you to avoid
null. That instruction was true and is not any more.
A safeguard on the rows this actor gives you for nothing. On the current pricing nothing about your runs changes.
- A row you are not charged for can no longer be billed to you by accident. Sample rows, the row that names an input mistake, the row a country with no trends returns, and the run summary at the end of your dataset all carry no result fee — and the run now checks, before it writes any of them, that the actor's billing genuinely charges nothing for them. If it ever did not, those rows are left out and their counts are reported in the run status line and the run's OUTPUT record instead, so you still see exactly how many countries came back empty and what went wrong with your input. Under this actor's pricing today every one of those rows still ships exactly as before.
- Every delivered row states its charge correctly under any billing setup, so the
charged column you reconcile an invoice against stays true even if the pricing behind the actor is ever changed.
This page now states the price up front. Nothing about what this actor delivers or charges changed.
- The price is on the page, not only in the store header. From $0.50/1,000 trending searches — all-inclusive pay per event, no start fee, charged only on delivery — the same figure the store header and the Pricing tab already showed.
A country whose first request came back as something other than the trending list is now retried before anything is reported.
- A blocked or unreadable first answer no longer ends the country's turn. When Google's reply was a consent page, an error page or an unreadable response, the run used to report that country as re-runnable straight away, without trying again. It now retries on a fresh connection first — up to three attempts per country, with a short pause between them — and reports the country as re-runnable only if every attempt failed. More countries come back with their trends on the first run; the uncharged re-run row is unchanged for the ones that still cannot be reached.
- Rate-limited and dropped requests get the same three attempts, up from two, with the same pause between them. A country Google itself rejects (an unknown country code) is still answered immediately and never retried, and a country that genuinely publishes nothing still gets its honest empty row without a retry.
Suite links now point at the full live shelf — every actor named in this README is a live
store link. Nothing about what this actor delivers or charges changed.
Review-fix build: cleaner bookkeeping for moved and resurrected runs, and empty settings now read as defaults.
- A moved or resurrected run can no longer leave two summary rows in your dataset. The run's summary is now written so that a later server recognises it as already delivered; previously a restarted run that had new rows to add could append a second summary beside the first. The summary's charge counts now also always cover the whole run rather than the last server's share of it, and summary rows are never mistaken for trending searches when a resumed run counts what it has already delivered.
- A resumed run that cannot trust its own delivery record now stops rather than charging again. Right after a run is moved or resurrected, the dataset read-back can momentarily lag behind what has already been charged. A run that trusted such a read would start the work over — fetching, delivering and charging a second time for rows you had already paid for. It now notices that its charges exceed what the record shows, stops cleanly without charging anything more, and says so. Re-running once the record has settled carries on normally.
- An empty numeric setting now means "use the default". Sending
null or an empty string for a numeric option — as templated API callers often do — used to be read as zero and clamped up to the smallest allowed value. It is now treated as not set and gets the documented default.
A run that runs out of time now stops cleanly instead of being cut off.
- A run close to its time limit now stops itself, with its summary intact. A country's request can take up to half a minute, so a run that had just enough time left to start one could be cut off by the platform mid-request — losing the summary row that tells you what was delivered and what is still owed. The run now declines to start a request it cannot finish, ends successfully, and hands back the same summary and resume list any other clean stop produces. The country it did not reach is listed as still owed and is not reported as a country with no trends; nothing is charged for it.
- Your own
maxRunSeconds is now respected by the same rule, not just the platform timeout, so a short run you asked for ends the way you asked for it.
A country that could not be reached is now reported as something to re-run, never as a country with no trends.
- A blocked or unreadable response is no longer reported as "Google published nothing". When a request came back as something other than the trending list — a consent page, an error page, a truncated or empty response — the run used to say Google had answered normally and published no trending searches for that country. It was a temporary problem described as a permanent one, and it sent people away instead of back. Such a run now returns one uncharged row saying the request did not get through and asking you to re-run. A country that genuinely publishes nothing still gets the honest empty row it always did.
- A country whose trending list is not served now says so in its own words. It used to be reported as a country Google publishes no trends for. The row now says the list was not served on this run, invites a re-run, and notes that a country where it keeps happening may no longer have a trending list at all. It is marked re-runnable, and nothing is charged for it.
A typo in an input field name now gets a helpful pointer instead of sample rows.
- A misspelled field name is answered with the field you meant. Sending your country under a
name this actor does not have —
country instead of geo, say — or filling in only the limits
and no country, used to come back as the uncharged sample rows. Those samples are all stamped
US, so a run that asked for another country and misspelled the field read like a real answer
for the wrong one. Such a run now returns one uncharged row that names the field the actor did
not recognise, names the one it does, and shows the shape to send. Runs that do name a country
are unchanged, and a run with nothing set at all still returns the sample rows.
- Hardening in the shared Google Trends engine this actor is built on: a reply that comes
back valid but empty is now recognised as Google declining the request rather than
accepted as a genuine empty answer, on every surface the engine can read. Such a reply
is retried, and an answer that never arrives is reported as an uncharged miss. The
trending feed this actor reads already behaved this way, so its own output is unchanged.
- A run that gets moved to another server part-way through — or one you resurrect
from the console — now carries on where it stopped. Trending searches already in
your dataset are not collected again and are never charged twice, and the run
finishes only the countries it had not reached.
maxItems is now a limit on the whole run rather than on each restart. An
interrupted run could previously deliver up to twice the cap you set.maxRunSeconds and the actor's own time ceiling are measured from when the run
started, so an interrupted run no longer gets a second full time budget.- If a restarted run cannot read back what it already delivered and it has already
been charged, it now stops charging altogether and says so in the run status
instead of risking a second bill. Rows still ship, marked
charged: false.
- The suite directory at the end of this page now links straight to
Social Trends · 4 Platforms, which is live.
Initial release.
- Google's trending searches for any country, off Google's own trending feed.
- Poll several countries in one run — each is fetched independently, and one
country being unavailable never blocks the others.
- No start fee. You are charged per trending search delivered and nothing
else, so an hourly schedule costs the same per trend as a single run.
- Every row carries
charged, status and missReason, so the invoice
reconciles from the dataset itself.
- Nothing is charged for a country Google does not cover, a country that
published nothing, a request Google rate-limited, or trends your own
minTraffic filtered out. Each of those ships as an uncharged row that says
what happened and names the fix.
maxTrendsPerGeo, maxItems and maxRunSeconds are hard limits: the run
stops cleanly, still succeeds, and the final summary row names which limit
bound and which countries were not reached.- Running with no country set returns uncharged sample rows and contacts
nothing, so you can see the exact output shape before spending anything.
