Operations Monitoring
Sign in with Firebase Auth account that has custom claim admin=true.
This account is authenticated but is missing the required admin custom claim.
Command
Marketplace health, throughput, and reliability at a glance.
This is the safest first screen for daily operations. It summarizes marketplace health, active demand, technician availability, dispatch risk, payments risk, support risk, and shortcuts to the deeper tools.
This screen is read-only except for Refresh and shortcuts. It should not change real clients, technicians, requests, payments, or dispatch state.
Live means the value came from current Firestore/admin data. Manual refresh only means the page does not poll in the background, which keeps costs controlled.
Track the quote outcomes, market aggregates, and operational signals that help CrewHook get smarter with every job.
This dashboard uses aggregate marketplace data for internal operations. It does not expose individual competitor quotes to clients or technicians.
Collection control
Pause this before fake marketplace QA so test quotes do not contaminate future quote guidance.
Loading current collection settings...
Use this before running fake marketplace tests so test quotes do not contaminate future quote guidance.
Aggregate accepted quote outcomes by market, service, flow, and quote type.
Sanitized operational event stream for quote activity, reevaluations, issues, and completions.
Read-only monitor for risky request, quote, payment, reevaluation, and marketplace states.
Read-only operations monitor. This page does not repair records, capture payments, refund payments, retry dispatch, or write Firestore data.
Use these details to decide where to inspect next. This panel is read-only.
Admin-only backend health, latency, error, and load-test impact view.
System Health uses sanitized operational events only. It does not store customer addresses, payment details, AI prompts, or full request bodies.
Latency and status counts grouped by Cloud Function.
Latest sanitized failures in the selected window.
Highest latency operational events in the selected window.
Filtered sanitized telemetry stream for operator review.
Admin-only operating-cost estimates and usage pressure from sanitized backend cost events.
Cost & Usage is an internal estimate, not billing reconciliation. It uses sanitized aggregate units and does not store customer addresses, payment details, AI prompts, AI responses, or full request bodies.
Estimated cost and counted units grouped by source.
Function-level usage pressure from cost events.
Estimated usage grouped by individual scalability test run.
Events with the largest internal estimated cost.
Filtered sanitized cost-event stream for operator review.
Create safe test-mode request and quote data to verify CrewHook scalability without charging customers or polluting Marketplace Intelligence.
Load tests create test-mode records only. They do not call Stripe, do not capture payments, and do not send real customer or technician notifications.
Safe simulation
Dry run is enabled by default and creates no Firestore request docs.
Cleanup load-test data
Cleanup only affects records marked isLoadTest/testMode with the matching loadTestRunId. Real customer, technician, payment, and notification records are never modified by this tool.
Baseline report
Correlates the run record, generated projections, cleanup status, operational events, and estimated cost events.
Last 25 admin-triggered runs. Preview cleanup before archiving or deleting test-mode request records.
This page collects operational problems that may need a human decision: stuck dispatches, manual review requests, failed refunds, stale technician locations, failed notifications, techs busy too long, and requests waiting too long.
Do not cancel, retry, or force status changes from an issue row just because it appears in the list. The page shows candidates for review, not automatic proof of a failure.
Stuck broadcast means dispatch did not finish cleanly. Manual review means the backend intentionally stopped and wants operator input. Reconciliation means payment state needs comparison before refunds or captures.
Clients reported a problem before confirming completion. Review these requests before payment is captured or the client is allowed to confirm again.
This page lists customer service requests by status. Use it to inspect a request lifecycle, confirm who owns it, see dispatch/payment state, and take request-level admin actions when necessary.
Request actions can affect real users. Do not complete, cancel, reopen, or retry a request unless you have confirmed the request ID and the user-facing outcome.
Pending means still open for dispatch or scheduling. Assigned/accepted means a technician is attached. In progress means the job has started. Completed/cancelled should no longer appear as active work.
This page monitors dispatch waves and broadcast state. It helps admins see whether requests are being sent to eligible technicians and whether a wave is active, stopped, or waiting for manual review.
Do not retry broadcasts repeatedly. Retrying can notify technicians again. Use a single retry only after confirming the request is still open and eligible.
A wave is one dispatch attempt to eligible technicians. Skipped reasons explain why a technician did not receive the request.
This page lets admins inspect technician accounts, availability, dispatch eligibility, location freshness, service profile, and expertise used for matching.
Changing expertise or account status can remove a technician from matching or route wrong work to them. Confirm the technician ID and business reason before saving.
Accepting jobs means the technician can receive work. Busy does not automatically block broadcasts; if the technician is actively online and has no schedule or current-work conflict, they can still receive eligible jobs in their service line. Stale location means dispatch distance may be unreliable.
Click a row to load technician details. Saving expertise updates Firestore and limits broadcast matching to that service only (other trade/specialty fields are cleared).
Sets expertise to a single value and removes trades, specialties,
trade, and specialty so only this category matches new requests.
This page lets admins inspect client accounts and linked request history. It is mainly for support, identity checks, and troubleshooting customer-side issues.
Client profile data can include sensitive fields. Avoid copying full profile data into screenshots or external messages.
Client ID is the Firebase UID for the account. It is more reliable than name or email when searching logs and requests.
Click a row to load client details.
Find, inspect, and act on payment records safely.
This page helps admins find payment records, inspect Stripe/payment state, review refund status, and hide test payment records from the admin list without deleting financial history.
Refunds and payment actions affect real money. Confirm the request ID, payment ID, amount, client, technician, and reason before pressing Confirm Refund.
Authorized means funds are reserved but not fully captured. Captured means funds were charged. Refunded/partially refunded means money was returned through the refund flow.
This page shows requests that the backend has intentionally held for admin review instead of continuing automatically. It is for ambiguous or risky situations that should not be auto-resolved.
Manual review exists to prevent accidental automation. Do not bulk-clear these records without checking the underlying request.
Operator intervention means the system needs a human decision before continuing.
In-app issue reports from technicians and clients (stored in supportCases).
This page collects in-app issue reports from clients and technicians. Admins can review the report, send an outreach message, load the linked request, and mark the support case resolved.
Support messages may trigger push notifications. Avoid sending duplicate messages and avoid promising refunds, technician changes, or timing before verifying the request record.
Outreach log is admin-only history of messages sent from this page.
Sends a push notification when the recipient has a registered device. Messages are appended to the outreach log below (admin only).
This page manages out-of-market waitlist contacts and launch outreach. It is for future-market growth, not active Miami dispatch operations.
Do not notify selected contacts from an unfiltered broad list. Marketing outreach affects trust and can look like spam if sent to the wrong group.
Waitlist means a user expressed interest outside the current service area or before launch in that location.
Manage out-of-market waitlist contacts for launch outreach by role, status, geography, and signup date.
This page contains high-impact operational controls for requests, technicians, safety switches, stuck broadcasts, and dispatch tests. It is powerful and should be used deliberately.
Ops Tools can change real production behavior. If you are unsure, stop and inspect in Command Center, Requests, Dispatch, or Technicians before pressing an action button.
Safety controls are emergency switches. Dispatch tests create real backend objects and can notify accounts unless isolated to test users.
Request controls change one request at a time. Use them only after inspecting the request record and confirming the customer-facing outcome.
Never use Retry Broadcast on an already accepted, scheduled, in-progress, completed, or cancelled request unless the backend state clearly supports it.
These controls change whether a technician can receive or continue work. They are for urgent operational corrections, account issues, or safety responses.
Confirm the technician ID first. These buttons can immediately affect their access and job flow.
Safety controls temporarily disable broad categories of automation. They are intended for incident response, not routine operations.
Turn off the smallest switch needed, write down why it was changed, and turn it back on only after verifying the incident is resolved.
Warning: this creates a real dispatch request and can notify technicians. Use test technician accounts only.
The dispatch test is useful for validating matching, fanout, and acceptance behavior without using a real customer booking. This tool uses real backend functions. Treat every test as production unless the selected accounts are confirmed test accounts.
Dispatch test checklist
Test-only score fields. Real technician ratings cannot be edited here.
Select a preset or radius helper, or enter manual coordinates.
Use this monitor immediately after creating a dispatch test to verify whether matching, pending docs, acceptance, cleanup, and state restoration worked.
Do cleanup before leaving the page. Leftover test pending docs can confuse mobile testing.
This page controls system-wide operating modes, cost/safety settings, test sandbox behavior, and advanced tuning. It is the highest-impact admin area.
System changes can affect dispatch, notifications, cost, safety behavior, or testing. Do not change advanced tuning unless you have a specific reason and a rollback plan.
Mode means the system-wide operating posture. Advanced tuning changes thresholds and behavior that can affect many users at once.
The sandbox runs fake service-flow tests using isolated test collections. It is designed to exercise the system without touching real client or technician records.
Sandbox is low cost, but repeated full test runs still create reads and writes. Use it intentionally.
This is fake test data only. Cost impact: very low. It uses isolated docs:
testRequests, testUsers, testSandboxTechs, and testPayments.
It does not affect real clients or technicians.
Basic controls expose common system mode switches in a safer format than raw backend configuration.
If a control changes dispatch, notifications, chat, or payments, test the affected flow after saving.
Advanced tuning changes thresholds and backend behavior that may affect cost, dispatch speed, abuse limits, or incident response.
Do not use advanced tuning for experimentation during live traffic unless the change has a rollback plan.
This section shows pending system-control changes before they are written. It is the final checkpoint before production behavior changes.
After saving, monitor the affected function logs and mobile flow before making more changes.
Refunds return money to the client through the payment provider and create financial history that should not be deleted.
Repeated refund attempts can create reconciliation work. If the first attempt fails, inspect the error before trying again.
Hiding removes confirmed test records from the admin payment list. It does not delete payment records, request records, or Stripe history.
Never hide a real client payment just to clean the screen. Use filters instead.