> For the complete documentation index, see [llms.txt](https://deep-rock.gitbook.io/auto-stop-services/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://deep-rock.gitbook.io/auto-stop-services/faq.md).
# FAQ
{% hint style="warning" %}
**Documentation has moved!**
Please go to:
\
*This Gitbook is no longer updated.*
{% endhint %}
Is there a delay for your extension to trigger?
The short answer is that there could be. This extension, and pretty much any approach using Cloud Billing, is at the mercy of Google Cloud. If there is a delay in Google Cloud calculating billing, then naturally this will mean the extension will trigger later than what is ideal. However, in my experience, this has not been a big issue.
An excerpt from the [Firebase documentation](https://firebase.google.com/docs/projects/billing/avoid-surprise-bills) around this:
> Depending on the Google Cloud or Firebase service, sometimes there's a slight delay (up to a few days) in usage reporting to Cloud Billing. This reporting delay impacts the calculated spend during the budget period and can cause a delay in the generation of budget alert notifications.
What do I do once the extension is triggered?
When the extension is triggered, it will stop services in your Firebase project based on the "strategy" you select. To recover services, see the detailed guide over on the [Recovery](/auto-stop-services/publish-your-docs.md) page.
Why am I getting logs from this extension?
Logs are generated when the extension receives alert from Google Cloud Billing via Budgets. At the time of writing, for any alert generated it will be logged by the extension.
Alerts are also generated periodically by GCP, even if a threshold hasn't been met. This is OK behaviour as this extension only responds to configured thresholds being met or exceeded.
Excerpt below from the [GCP documentation](https://cloud.google.com/billing/docs/how-to/budgets-programmatic-notifications):
> * Budget notifications are sent to the Pub/Sub topic multiple times per day with the current status of your budget. This is a different cadence than the budget alert emails, which are only sent when a budget threshold is met.
> * Pub/Sub notifications are sent even if the Cloud Billing account has no usage.
> * Pub/Sub only guarantees at-least-once delivery. You might receive a message multiple times, and messages might arrive out of order.
We do not expect high volumes of logs. However you can filter these out in your log queries.
What stop strategy do you recommend?
Strategies are outlined in this guide. However, the recommended approach is Strategy 1 (removal of Billing Account from your project) due to it's simplicity.
What can I do if I find an issue or have questions?
Feel free to raise an issue or questions in the [GitHub repository](https://github.com/deep-rock-development/auto-stop-firebase-ext). It is an open source extension, and you are more than welcome to submit pull requests / code changes.
We periodically update the extension to be up-to-date with Firebase, and in conjunction with user feedback. We also update this guide. So any requests, issues, or questions are welcome.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://deep-rock.gitbook.io/auto-stop-services/faq.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.