Any word on the fix ? Still the issue persist after 17 hours.
Is this also in some way related to my current issue as well? like how google scripts are not resolvable?
Given the above, I would assume that google scripts has been blocked too unless admin says otherwise
Well as he replied to my message saying it was / is a technical issue Ig its not?
Since why google really? If that is the case I would not have any other option than to switch to something else.
The main reason for blocking an external script provide is to stop people circumventing the restrictions here.
Same reason as blocking cloudflare workers
Totally understand the issue and everything but if this do this for every background worker like official for cloudflare and god hope not google scripts we will eventually run out of options for the people who actually need these and have no intention to circumvent restrictions.
Or of interest, what do you need this for? The only thing I can think of is accessing blocked APIs like Telegram
You mean “out of interest” ? Well I use google scripts to handle my Status I know unreliable but its extremely small stuff and it used to work smoot as butter but now it does not it never connects reason could not resolve google . scripts Here
https://thesecretary-status.gt.tc/
I created a post of this earlier yesterday Admin Said its a technical issue will be fixed in an hour or so its been 21 hours still same thing.
I moved your questions about your other topic to the topic the question relates to.
But I’m sorry to say that your guess is right: the domain script.google.com was also blocked for similar reasons as workers.dev.
I know I said it was a technical error. I was basing that on incorrect assumptions and conflating two different issues. But I was wrong, and some lines got crossed in communication earlier so I only found out the real answer a few hours ago.
So does that mean ITS PERMANENT? and it will never be able to resolve scripts.google. com?
Hell Nah Please No!
Is there any workaround or anything that can make this work?
Have we hit the
“There is nothing we can do”
limit?
In short: yes, it’s permanent. Accessing script.google.com will not be possible in the foreseeable future.
That depends on what “this” is exactly.
I’m happy to think about potential ways for you to restore your website functionality without using Google Apps Script.
But I cannot help you access Google Apps Script anyway. It’s deliberately blocked for a reason, and I’m not going to tell you how to bypass intentional restrictions.
I’m happy to think about potential ways for you to restore your website functionality without using Google Apps Script.
I would love that sure, course its not possible to actually access it now.
I don’t understand what you mean by that.
Right now your website is not working, so we can’t see it. But you can still explain what the Apps Script part was doing, and maybe we can think of an alternative.
It’s all up to you though. If you’d rather not discuss it here, that’s fine too.
I mean the website is live anyhow just it does not connect to google scripts the status of my original website is unfetchable, but yeh I mean I used google scripts to read a particular Json status at /health of my website which notifies about any downtime. Google scripts was my best bet and since almost all such scripts or workers would have been blocked i don’t see an alternative at this point.
I still don’t understand what you mean.
There is a /health endpoint on your “original website”? Is that “original website” the website you’re hosting with us or a website somewhere else? If it is the website with us, then why do you need to round trip around Google Scripts to get data from your website into your website? And if not, then why not just connect to the original website straight from the website you have with us?
And what does any of this have to do with uptime monitoring?
I don’t understand what part Google Scripts actually plays in the whole process. And If I don’t know what role it plays, I cannot suggest an alternative.
Again, not sure why you need scripts or workers in the first place. And I’m not familiar with Google Apps Script, so I cannot think of anything special it does that cannot be replicated elsewhere.
There is a
/healthendpoint on your “original website”? Is that “original website” the website you’re hosting with us or a website somewhere else? If it is the website with us, then why do you need to round trip around Google Scripts to get data from your website into your website?
Well No offence, Course if the website was with Infinity free I wouldn’t have a google scripts as a middle man and probably won’t have a status page at all since Infinity free has its own.
My original website is hosted on Render, and the status page acts like the “uptimerobot” website you might already know about, I wanted to created my own such status page for my website, since uptime robot does not allow maintenance pages and custom incidents reports and also emails from my custom address, that was the major reason I initially created a status page but then the status page became a necessity when I started publishing posts, and scheduled maintenance which again uptime robot does not allow (it does allow, just not in free plan(s))
Google Apps Script in all this?
Google Apps Script is the monitor backend. It runs on a timed trigger, requests site/health, records whether it responded and how quickly, saves history/incidents, and exposes that result to the status site.
InfinityFree could only replace it if it runs a reliable scheduled server-side script that can:
- Poll Render every few minutes
- Store uptime history in a database
- Serve the latest status as JSON
Continue running independently even while Render is down, basically the whole point of a status page
A normal InfinityFree-hosted webpage cannot do that by itself: browser JavaScript runs only while somebody has the page open, is subject to browser/CORS limits, and cannot reliably create scheduled monitoring history.
Furthermore, I tried cron a while back in a different free website service like infinity free and they do no support that or something I don’t remember correctly but it gets your website suspended for 24 hours real fast.
I’m afraid InfinityFree isn’t designed or intended to run any kind of long running processes like that. The only server-side language it supports is PHP, scripts will only run when a visitor actually triggers it, and the execution time limit prevents them from running for long. Even paid shared web hosting generally doesn’t support long running processes. Using a VPS, or another application hosting service (instead of or in addition to Render) would be a much better fit.
And yes, cron jobs have been banned on InfinityFree and other MOFH based hosting services for a while now. That includes using third-party solutions to trigger them.
I understand and know that, and this is exactly why I used google scripts as they were the easiest path, allowing me to both use infinity free which I know and been using since a while along with my desired website, but I understand if there no alternative to this now I would have to switch this to something else.
Thank you for that explanation, that makes a lot more sense.
So, to make sure if I understand it correctly: your main website is running on Render, and you want a white label uptime monitor for that. So Google Script pings the website on Render, and the status page on our hosting connects to Google Script to get the status information.
Honestly, it’s a very specific use case and I can think of about a dozen different approaches that would work around this limit, and I must admit that there isn’t a good use of InfinityFree in some of them.
But here is one suggestion: you say you want something like UptimeRobot but don’t want to pay for their white label features, then why not just build that on our hosting? You can host the status page with us and have it pull the data from UptimeRobot’s API. Then you can make the status page however you want to, without UptimeRobot’s status page limitations and without having to build your own status monitoring system from scratch.
The API has fairly low rate limits on the free plan, only 10 requests per minute. But that’s something that can be solved with caching on the status page side, either in a file or in a database.