Guides And Operational Playbooks
This documentation hub is designed for builders who want reliable monitoring, predictable billing, and fewer release-day surprises. Each section below explains not only what to click, but why the workflow matters in production.
Getting Started
Use this path when you are setting up PulseForge for the first time and want a stable production-friendly baseline.
Create or sign in to your Firebase-backed account from the auth page.
Open the dashboard and add a lightweight health endpoint such as /health or /status.
Choose an interval that matches the target service tier. For most public apps, start with 60 or 300 seconds.
Run a manual monitor request once to confirm the target responds quickly and consistently.
Review logs and analytics before adding more endpoints so your first project becomes your known-good template.
Endpoint Design
Monitoring works best when the endpoint is intentionally built for monitoring instead of reusing a heavy application route.
Prefer GET or HEAD checks against a dedicated health route with no expensive database joins.
Return a small 200 response body and avoid rendering templates or large JSON payloads.
If your target needs auth, use custom headers only when absolutely necessary and rotate secrets regularly.
If you monitor a cold-start-prone host, keep the endpoint simple so wake-up traffic does not create false alarms.
Watch the first few logs after deployment; a successful endpoint should be predictable, fast, and boring.
Alerts And Billing
Billing and alerting should be verified together because bad alert timing often looks like a billing or auth problem.
Confirm your plan and remaining credits from the billing page before running repeated manual tests.
Use Pro or Business plans when you need larger credit pools or longer operational history.
Treat timeout-heavy targets as an application issue first, not a monitoring problem.
When testing Razorpay, verify order creation, checkout open, signature verification, and post-payment plan sync as separate stages.
Keep support workflows documented so failed payments or quota-related auth issues can be resolved quickly.
Security And Compliance
PulseForge is strongest when operational discipline and app security move together.
Store secrets only in Cloudflare Workers/Pages variables and never hardcode them into client bundles.
Keep Firebase project settings aligned across frontend and worker runtime environments.
Review robots, sitemap, privacy, terms, and security pages after every significant release.
Use narrow scopes for GitHub, Cloudflare, and payment-provider access tokens.
Treat exposed keys or tokens as incidents: revoke, rotate, redeploy, and document the change.
Troubleshooting Checklist
When something breaks, this sequence helps isolate whether the issue is app auth, worker auth, billing, or the target endpoint itself.
Check browser console and network status codes first. A 401 usually points to auth state or worker token verification.
Check worker logs for token verification errors, database binding issues, or upstream fetch failures.
Run a manual monitor request and compare its latency with scheduled results in logs.
If the target times out, verify the host manually in the browser or curl before changing app code.
After config changes, hard refresh the browser and clear stale session storage when debugging login-related problems.
Release Hygiene
Good releases reduce surprise. PulseForge now follows a cleaner release checklist that keeps product, content, SEO, and infrastructure in sync.
Run typecheck and production build before every push.
Deploy worker and frontend intentionally; do not assume one deploy updates the other.
Update changelog, roadmap, and policy content whenever behavior or billing changes.
Rebuild robots and sitemap metadata after adding or removing public pages.
Record the release objective, risk, rollback plan, and post-release verification notes.