Google Sheets -automaatio lakkasi toimimasta: 6 minuutin raja, käyttöoikeusvirheet ja milloin Apps Script ei enää riitä

Joku rakensi sen kolme vuotta sitten. Skripti siirsi Google Forms -vastaukset tilaustaulukkoon, lähetti joka aamu sähköpostin varastolle ja loi toimitustapahtumat tiimin kalenteriin. Kukaan ei tiedä, miten se toimii, ja tänä aamuna se pysähtyi. Taulukossa näkyy ”Exceeded maximum execution time”, tai sähköpostissa on ilmoitus, että triggeri ei suorittunut, tai sitten sen kirjoittanut henkilö lähti yrityksestä kesäkuussa ja hänen rakentamansa automaatiot pysähtyivät.

Kyse on Google Apps Script -ongelmasta, ja se on yksi yleisimmistä tukipyynnöistä, joita saamme yrityksiltä, joissa automaatiolle ei ole nimetty vastuuhenkilöä. Tässä artikkelissa: kolme vikatyyppiä, joita näemme muita useammin, miten kukin diagnosoidaan turvallisesti, ja hetki, jolloin rehellinen neuvo on siirtää automaatio muualle. Kiintiöt ja toimintatapa on tarkistettu Google Apps Script -dokumentaatiosta 9.9.2026.

Selvitä ensin, mikä tarkalleen ei toimi

Avaa laskentataulukko tai dokumentti, jossa skripti asuu, ja valitse Extensions, Apps Script. Jos automaatio on erillinen projekti eikä taulukkoon sidottu skripti, etsi se osoitteesta script.google.com. Vasemmalla oleva Executions-osio näyttää jokaisen suorituksen tilan ja virhetekstin sillä tilillä, jolla olet kirjautunut. Lajittele tilan mukaan ja merkitse viimeinen onnistunut suoritus. Yleensä näet yhden kolmesta kuvasta: punaisia rivejä tekstillä Exceeded maximum execution time, rivejä valtuutus- tai käyttöoikeusvirheellä, tai ei lainkaan rivejä viime päiviltä. Viimeinen ei todista, että triggeri on kadonnut: se voi tarkoittaa myös väärää projektia, väärää tiliä, suodatinta tai triggeriä, jonka omistajan tili ei ole enää aktiivinen. Avaa Triggers (kellokuvake) ennen kuin teet johtopäätöksiä.

Vika 1: 6 minuutin raja

Tavallinen Apps Script -suoritus saa kestää 6 minuuttia, sitten Google keskeyttää sen. Tämä koskee sekä yksityisiä että Workspace-tilejä. Yksinkertaisilla triggereillä, kuten onEdit, ja solujen mukautetuilla funktioilla raja on huomattavasti lyhyempi: 30 sekuntia. Yleisin syy siihen, että aiemmin ajoissa valmistunut skripti törmää nyt rajaan, on kasvu: kolme vuotta sitten taulukossa oli 400 riviä ja silmukka valmistui 40 sekunnissa, nyt rivejä on 40 000 ja sama silmukka tarvitsee 20 minuuttia. Se ei kuitenkaan ole ainoa syy: hidas ulkoinen palvelu, silmukka, joka käsittelee joka kerta kaiken uudelleen, tai kaavoilla ylikuormitettu taulukko tekee saman, joten katso Executions-lokista, kuinka kauan suoritukset kestivät ennen virheiden alkamista. Samalla tavalla purevat päiväkiintiöt: triggerien yhteenlaskettu suoritusaika päivässä (90 minuuttia yksityisillä tileillä, 6 tuntia Workspacessa), sähköpostin vastaanottajien määrä päivässä (100 yksityisillä, 1500 Workspacessa) ja URL-pyyntöjen määrä. Kiintiöt ovat käyttäjäkohtaisia, ja Google muuttaa niitä ajoittain, joten pidä lukuja tämän vuoden lukuina.

Ratkaisut halvimmasta työläimpään

1. Lopeta lukeminen ja kirjoittaminen solu kerrallaan. Suurin syyllinen. Skripti, joka kutsuu silmukassa getValue() ja setValue(), ottaa jokaisella kierroksella yhteyden laskentataulukkopalveluun. Koko alueen lukeminen kerralla getValues()-kutsulla, käsittely muistissa ja kirjoittaminen takaisin kerralla setValues()-kutsulla on huomattavasti nopeampaa: Googlen omalla parhaiden käytäntöjen sivulla sama työ lyhenee yli minuutista noin sekuntiin. Useimmat rajaan törmäävät skriptit eivät törmää siihen enää tämän yhden muutoksen jälkeen.
2. Käsittele vain uusi. Ota käyttöön ”käsitelty”-sarake tai aikaleima ja ohita rivit, jotka skripti on jo käsitellyt. Merkitse rivi käsitellyksi vasta, kun sen työ on todella onnistunut, muuten epäonnistunut suoritus jättää rivejä ”valmis”-merkinnällä, vaikka ne eivät sitä ole. Päivittäinen työ, joka käsittelee joka kerta koko historian uudelleen, on toiseksi yleisin syy.
3. Jaa työ useaan suoritukseen. Tallenna edistyminen PropertiesService-palvelulla, pysähdy ennen rajaa ja anna seuraavan triggerin jatkaa siitä, mihin edellinen jäi. Lisää lukitus (LockService), jotta kaksi suoritusta eivät mene päällekkäin eivätkä lähetä viestejä kahdesti. Luotettava, mutta jonkun on ymmärrettävä koodi.
4. Arkistoi taulukko. Siirrä rivit, joiden kanssa yritys ei enää työskentele, erilliseen tiedostoon. Nopeampi skripti, nopeampi laskentataulukko, tyytyväisemmät käyttäjät.

Vika 2: käyttöoikeus- ja valtuutusvirheet

Ilmoitukset kuuluvat ”This app isn’t verified”, ”Google hasn’t verified this app”, ”This app is blocked” tai ”Authorization is required to perform that action”. Ne tarkoittavat eri asioita.

• ”This app isn’t verified” tai ”Google hasn’t verified this app”. Skripti pyytää pääsyä Gmailiin, Driveen tai Calendariin, ja Google näyttää varoituksen, koska OAuth-projekti ei ole käynyt läpi vahvistusta. Projektit, jotka kuuluvat yhdelle Workspace-organisaatiolle ja joita käytetään sen sisällä, on yleensä vapautettu vahvistuksesta, joten jos näet tämän varoituksen skriptissä, jota pidät sisäisenä, pysähdy ja tarkista: kuka omistaa Apps Script -projektin, mihin Cloud-projektiin se on sidottu ja mitä käyttöoikeuksia (scopes) se tarkalleen pyytää. Toimiston tai entisen ulkoistuskumppanin kirjoittama skripti voi asua heidän tilillään. Vasta kun omistaja ja käyttöoikeudet on vahvistettu, järjestelmänvalvoja valtuuttaa sen; älä opeta työntekijöitä painamaan ”Advanced” tottumuksesta.
• ”This app is blocked”. Useimmiten Workspace-järjestelmänvalvojasi on rajoittanut kolmannen osapuolen sovellusten pääsyä, ja silloin korjaus tehdään Hallintakonsolissa (Admin console): Security, Access and data control, API controls, Manage third-party app access, sallien juuri tämän skriptin niille käyttäjille, jotka sitä tarvitsevat. Lue ensin koko virhekoodi, sillä samat sanat voivat tulla myös OAuth-asiakkaan määritysongelmasta. Älä kytke valvontaa pois koko organisaatiolta äläkä luota automaattisesti kaikkiin ”sisäisiin” sovelluksiin: salli se yksi, jonka olet tarkistanut.
• ”Authorization is required to perform that action”. Skriptin käyttöoikeudet on peruttu, tai se tarvitsee nyt oikeuden, jota sillä ei aiemmin ollut. Valtuuta uudelleen suorittamalla funktio käsin, mutta valitse se huolella: sattumanvaraisesti valittu funktio voi lähettää viestejä tai ylikirjoittaa rivejä. Käytä vaaratonta, esimerkiksi pientä function autorizet() { Logger.log('ok'); }, joka käyttää samoja palveluja, ja suorita se tililtä, joka omistaa triggerit.
• Mikään ei toimi sen jälkeen, kun kollega lähti. Asennettavat triggerit suoritetaan niiden luoneena henkilönä, ja kun hänen tilinsä jäädytetään tai poistetaan, ne pysähtyvät. Tiedoston siirto nykyiselle työntekijälle ei siirrä triggereitä: uusi omistaja ei edes näe toisen käyttäjän asettamia triggereitä. Selvitä siis, mitä skriptin piti tehdä ja milloin, luo uudet triggerit olemassa olevalta tililtä, tarkista ensimmäiset suoritukset Executions-lokista ja seuraa, ettei synny duplikaatteja, jos vanha tili on vain jäädytetty ja se voidaan palauttaa. Liiketoiminnalle tärkeiden automaatioiden triggerit kannattaa luoda erilliseltä Workspace-käyttäjätililtä (esimerkiksi ”automaatio@”), jolla on oma lisenssi ja kaksivaiheinen vahvistus (2SV) ja josta vastaa IT, ei skriptin kirjoittaja. Se on hallinnoitu käyttäjätili, ei Google Cloud -palvelutili: Apps Script -triggerit eivät voi suorittua palvelutilinä.

Vika 3: Google muutti jotain

Harvemmin, mutta sitä tapahtuu. Apps Scriptin vanha Rhino-suoritusympäristö suljetaan (Google asetti aikaisimmaksi sulkemispäiväksi 31.1.2026), ja hyvin vanhat skriptit, joita ei koskaan siirretty V8:aan, voivat lakata toimimasta tai käyttäytyä eri tavalla. Avaa projektin asetukset ja tarkista, mitä suoritusympäristöä se käyttää; Googlen V8-siirto-opas luettelee rakenteet, jotka hajoavat. Joskus jonkin Google-palvelun toiminta muuttuu, ja siihen luottanut skripti hajoaa. Tarkista Executions-lokista, onko virhe uusi ja aiemmin näkemätön, ja hae sen tarkalla tekstillä. Jos se on ilmestynyt samana päivänä monille, vika on todennäköisesti Googlen puolella, mutta ”odota päivä” käy vain, jos liiketoiminta sen kestää; muuten siirry manuaaliseen varajärjestelyyn ja säilytä lokit.

Milloin automaatio kannattaa siirtää pois Apps Scriptistä

Apps Script sopii pienten työnkulkujen yhdistämiseen: lomake, joka täyttää taulukon, taulukko, joka lähettää muistutuksen, kalenteri, joka heijastaa aikataulua. Se on väärä työkalu heti, kun yksikin näistä pitää paikkansa:

• Se törmää edellä kuvattujen korjausten jälkeenkin 6 minuutin rajaan, tai päiväkiintiöiden käyttö lähestyy rajaa.
• Jos se pysähtyy, liiketoiminta pysähtyy, eikä kukaan huomaisi sitä kokonaiseen päivään, koska valvontaa ei ole eikä virheilmoituksille ole vastaanottajaa, joka vielä työskentelee yrityksessä.
• Sitä on korjannut useampi ihminen, eikä kukaan heistä osaa selittää, miten se toimii.
• Siitä on tullut yrityksen tilaus-, varasto- tai asiakasjärjestelmä, jossa useat ihmiset kirjoittavat samaan taulukkoon yhtä aikaa. Sheets ei ole tietokanta, eikä skripti tee siitä sellaista.

Rivien määrä ei yksin ratkaise: 40 000 riviä osissa käsiteltynä on kunnossa, 400 riviä samanaikaisilla kirjoittajilla ja ilman virheenkäsittelyä ei ole. Sitten valinta, pienimmästä työstä alkaen: siistitään nykyinen skripti ja annetaan sille vastuuhenkilö, valvonta ja lukitus; jätetään taulukko käyttöliittymäksi, mutta siirretään raskas käsittely pieneen Cloud Run -palveluun; tai siirrytään valmiiseen liiketoimintajärjestelmään, joka tekee tämän työn jo. Mikään vaihtoehdoista ei ylläpidä itse itseään: Cloud Run -palvelu, jota kukaan ei valvo, on yhtä pimeä kuin skripti, jota kukaan ei valvo. Sanomme tämän yrityksenä, joka on kirjoittanut ja ottanut haltuunsa paljon Apps Script -ratkaisuja: pienet, selkeästi rajatut ja nimetyllä vastuuhenkilöllä varustetut ovat ne, jotka jatkavat toimintaansa.

Usein kysytyt kysymykset

Kuinka pitkään Google Apps Script voi suorittua?

6 minuuttia tavallisessa suorituksessa, sekä yksityisillä että Workspace-tileillä. Yksinkertaisilla triggereillä ja solun mukautetuilla funktioilla raja on 30 sekuntia. Lisäksi vaikuttavat päiväkiintiöt triggerien suoritusajalle, sähköpostin vastaanottajille ja URL-pyynnöille, jotka ovat Workspace-tileillä korkeammat.

Miksi skripti pysähtyi, kun työntekijä lähti?

Asennettavat triggerit suoritetaan niiden luoneena henkilönä. Kun tämä tili jäädytetään tai poistetaan, ne pysähtyvät, eikä kukaan muu näe näitä triggereitä tai voi korjata niitä. Luo ne uudelleen olemassa olevalta tililtä, mieluiten erilliseltä automaatiokäyttäjältä, ja tarkista, ettei synny kaksinkertaisia suorituksia.

Voiko Workspace-järjestelmänvalvoja nähdä, mitä skriptejä yrityksessä on käynnissä?

Osittain. Hallintakonsolin API controls -osio näyttää OAuth-sovellukset ja niiden käyttöoikeudet, ja Google Cloud -konsoli luettelee Cloud-projektiin sidotut Apps Script -projektit. Yksittäisissä taulukoissa olevia skriptejä ei luetteloida keskitetysti, mikä on hyvä peruste säilyttää liiketoimintakriittiset skriptit IT:n hallinnoimalla jaetulla Drive-asemalla.

Aiheeseen liittyvät artikkelit

• Google Workspace -tili on jäädytetty. Mitä tehdä?
• Miten saat Google Workspace -tukea, kun jokin ei toimi
• Hallinnoidut IT-palvelut Google Workspace -yrityksille

Jos skripti, josta liiketoimintasi riippuu, on pysähtynyt, lähetä meille virheteksti Executions-lokista, viimeisen onnistuneen suorituksen ajankohta ja yksi lause siitä, mitä skriptin pitäisi tehdä; niiden perusteella osaamme yleensä nopeasti sanoa, onko kyse pienestä korjauksesta vai uudelleenrakentamisesta, ja sopia työn laajuudesta ennen kuin mihinkään kosketaan.

Automaatio pysähtynyt eikä kenelläkään ole siitä vastuuta? Arvioimme työnkulun, triggerit ja suoritustilit, sitten sovimme korjauksesta ja ylläpitosuunnitelmasta vastuuhenkilön kanssa. Varaa maksuton 30 minuutin auditointi tai soita +371 22 30 50 90.

Arvioi automaatio