Skip to main content
Preview guidance. Review the decisions and proposed changes before applying them to your product.
Decide whether Metronome remains part of your customer install and who owns its account. Retention, customer ownership, replacement and removal require different work. Start with the external-service decision process; changing an API token does not replace your application’s usage or access policy.

Trace usage and application decisions

Inspect native signup and organization creation, usage emitters, delayed jobs, contract setup, balance or quota reads, callbacks and billing screens. Determine whether your application uses provider information to grant access, limit consumption or display charges. Inventory required local reference data and remote identifiers. An application can require a local plan row or customer-to-contract mapping before a user can create ordinary application data. Infrastructure and migration success alone do not prove that bootstrap is complete. Keep metering, rating, payment collection and application entitlements distinct. Decide which of these functions belongs in the customer product and define the behavior of any replacement.

If you retain Metronome

Choose the account owner and a supported setup procedure. Reconcile the application’s expected metrics, products, rate cards, customers and contracts with that account. Metronome’s API token selects sandbox or production, so verify the intended environment before testing. See its API quickstart. Preserve event identity and the mapping to the intended customer or ingest alias when retrying usage. Metronome uses transaction_id for deduplication; see sending usage events. Keep usage data and credentials within the agreed customer/vendor ownership and data-handling arrangement. If Metronome sends invoices to Stripe, review both customer and contract billing-provider configuration and the mapped Stripe account/customer. Changing either provider’s credential does not establish those relationships. See Metronome’s Stripe invoicing guide. Where the application consumes notifications, authenticate the notification or retrieve authoritative provider state before acting. Handle retries and duplicates without applying a business change twice. Follow Metronome’s webhook guidance.

If you replace or remove Metronome

Agree on the replacement for usage accounting, credits, quotas, contracts and access decisions that your application actually uses. Include data retention and billing-history requirements. Do not invent balances, quota seeds, contracts or an undocumented bypass to make signup succeed. Review the complete application and deployment change: stop or migrate usage producers, handle delayed events and callbacks, update consumers and local schema/reference data, and preserve a supported upgrade path. Remove unused secrets and infrastructure after their consumers are resolved. The vendor chooses and approves this behavior; Tensor9 does not infer removal from missing credentials.

Check the chosen behavior

For retention, use approved sandbox setup and produce a known usage event through the real application. Read its expected rated quantity and draft charge, along with the application-facing result. An accepted ingest response alone does not prove the event matched the intended metric or invoice. Metronome’s API quickstart describes those checks. Test duplicate events, missing mappings and provider outages against the chosen product policy. If invoice delivery is in scope, independently verify the expected sandbox invoice with the mapped billing provider. For replacement or removal, verify fresh native signup, core application create/read-back, delayed jobs and the replacement entitlement policy with Metronome absent. Exercise a supported upgrade and confirm required history remains accessible. Keep failed and unexecuted checks visible in the onboarding report. The shared catalog used by the onboarding skills supplies questions and research cues. It cannot supply account credentials, approve a product decision or establish a working install.