Customer guide · Private pilot

From connection to results.

Plimie checks which features you pay for, whether you use them, and whether they're set right. Then it tells you what to fix first.

The free pilot is invitation-only. Request a sign-in link, open it in the same browser within ten minutes, and confirm sign-in. Create a workspace to begin. The public sample is fictional.

1. Understand access

Confirm the supported connection and assessment scope with your pilot contact before creating a token. Plimie supports a defined set of checks; it does not connect to every infrastructure platform. Use a customer-controlled, account-owned, account-scoped, read-only API token. Never share a master account key or paste a token into chat. Grant read access only to the inventory, firewall rules, traffic analytics, cache and feature settings, API inventory, and load-balancer health configuration required by the agreed checks. Add account-level Billing Read to let Plimie inspect subscriptions; missing billing access leaves commercial conclusions unknown while technical checks continue. Confirm that the token has no edit/write permissions. Enter the account ID and token only in the authenticated workspace connection form. Verification checks account ownership and zone inventory; each check's evidence is validated separately during the scan.

Permissions vary by account and plan. A missing scope reduces assessment coverage; it does not prove a feature is disabled. Review the data and access contract.

Optional: Account Audit Logs: Read. Add this read-only permission if you want the finding chart to show when firewall settings changed (for example "Switched to log-only" or "Site added to rule"). Without it, Plimie shows only the changes you record yourself. It can't change anything in your account.

2. Choose what to assess

Select 1–10 zones and explicitly identify production and test environments, then start an assessment. You can leave and return while it runs. The pilot allows six new scans per workspace per hour. Owners can optionally provide an origin-transfer unit cost. Bot-related fields are inspected directly in security rules without subscription confirmation. Subscription checks run separately from technical checks. A current paid subscription with a disabled setting can identify a spending review; limited configuration gaps do not prove complete non-use or removable savings.

Filter your view

Use Showing above Past scans. Each account shows its ID and name, with zone IDs and names underneath. Select an entire account or individual zones across multiple accounts, then choose Apply. Past scans and findings follow your selection. This doesn't change what gets scanned, your notifications or past reports.

Paid features and settings

In Past scans, choose Coverage →. Each check says In use or Not in use, and Set right or Needs attention.

3. Read a finding

• What we saw: what was observed, where, and over which complete days.
• Next step: a practical investigation or change to review.
• Impact: why it matters.
• Effort & risk: what to consider before changing production.
• More details (evidence, confidence, assumptions): the evidence behind the finding, how strong it is, and what it cannot establish.

In Past scans, choose Coverage → to see cache-status observations for seven complete UTC days, where your plan and permissions allow. Zone totals and owner-confirmed hostname/path traffic are shown separately, with sampling and daily coverage. These request and visitor-response byte totals are not recommendations or savings estimates. Private/dynamic traffic is not assumed waste, and revalidated response bytes are not origin downloads. Miss persistence in the selected traffic does not prove repeated misses for the same object or exclude purge artifacts.

For cache configuration coverage, include read access for legacy page rules, cache rules, and zone settings. The pilot checks active legacy page rules without changing them. Missing access keeps the affected check Explore. Supported cache rules and zone settings receive a conservative configuration review; active legacy page rules and unsupported settings remain review gaps. Only legacy page-rule IDs and priorities are retained, not target URL patterns or action values. Owners must freshly confirm that purges, deployments, development mode, or cache-policy changes did not explain misses in this scan's exact seven-day window. MISS/EXPIRED traffic must occur on at least three distinct days, alongside the other volume and origin-contact gates. This measures persistence within the selected traffic, not repeat misses for the same file.

4. Give feedback and track work

Rate a finding Correct, Partially Correct, or Incorrect. Keep that verdict separate from its lifecycle: Reviewing, Accepted, Planned, Implemented, Dismissed, Resolved, or Stale. An accepted finding is not proof of realized savings.

5. Measure the result

On a finding's Past checks, choose Use as baseline and Use as follow-up, then Compare selected scans. Comparing doesn't change your status or results. Configuration changes do not prove effectiveness. Cache origin-contact share changes are shown only for matching traffic scopes with complete, unsampled, non-overlapping seven-day windows and matching rule versions; missing or incompatible evidence leaves the change unavailable. Source links open each protected scan.

Technical comparability does not establish equivalent workload, change timing, or causation. Record what changed separately, and report realized monetary value only when you have measured it. Changes in traffic, cache intent, and application behavior can affect comparisons; an observed difference is not verified savings.

To attach a comparison to a result, a workspace owner must select both scans, enter the change time in UTC, and explicitly confirm change timing and comparable workload. The server checks evidence and timing again when saving. The result preserves the owner's confirmation and source scans; confirmation is not independent verification of causation or savings. Members may still record a standalone customer report, which is labeled separately. Selecting different scans clears the confirmations.

6. Export your workspace

Owners can download a revision-checked NDJSON archive of their workspace, evidence, assessment history, feedback, results (outcomes in the export file), and audit records. Credentials and sign-in data are excluded. Wait for scans and edits to stop; a concurrent change cancels the download. The browser supports files up to 100 MiB. Read the export format, limits, and paginated API guide. Store exports securely; they contain private workspace data.

What each check means

For managed WAF, an execute target must match a provider-listed managed ruleset in the WAF phase, and the entrypoint must agree with its inventory. Missing metadata, uncertain applicability, or conflicting reads remain coverage gaps. Confirmed deployment does not prove that overrides, exceptions, or individual rules provide effective protection.

Current live coverage: managed WAF deployment, daily HTTP traffic, owner-confirmed selected cache traffic with supported configuration review, the tiered caching setting, standard load-balancer health-monitor configuration, and bot-field references in enabled custom WAF and rate-limiting rules with bounded nested policy inspection, followed by seven-day bot/security traffic review. Real customer cache behavior and security-rule inventory coverage still need validation. Custom load-balancer rules, pool sets, omitted fields, and incomplete inventory remain Explore. Monitoring-only or disabled group members do not count as health steering. Fallback-only pools are excluded, and production/test classification inherits the selected zone context. Sampled or incomplete traffic cannot support a finding under the pilot's current policy.

EDGE-001 · Managed WAF deployment

Checks both zone and applicable account scope before concluding no deployment exists.

EDGE-007 · Cache realization

Looks for repeated origin contact in eligible static traffic. Private, authenticated, API, and intentional bypass traffic is excluded.

EDGE-006 · Tiered caching

Requires an authoritative off state and meaningful cacheable traffic. It is grouped under the cache finding when both apply.

EDGE-008 · Health monitoring

Accounts for monitor groups as well as legacy monitors across referenced pools.

EDGE-003 · Bot traffic review

Inspects enabled security rules for bot score, JA3/JA4, detection IDs, verified-bot and related fields, including counting expressions and rate-limit characteristics. Shows rule IDs, actions and scope; missing permissions remain gaps. No subscription confirmation is required. When use is confirmed in an active, non-test zone, checks continue through seven complete UTC days: score 1–2 request outcomes, score 80–99 blocking events, and blocks/challenges matching known API endpoints. Complete unsampled evidence can support a targeted review, with conditional next steps and rollback guidance.

Owners can provide these answers in zone setup, or leave them unconfirmed. Cache recommendations also require an owner-selected host/path prefix confirmed to contain only public, static content with no private/authenticated traffic or intentional bypass. Each scan records the answers, confirming owner, and time; later edits do not rewrite historical evidence. Confirmations alone do not establish a finding: all configuration, analytics, sampling, persistence and volume gates must pass. New scans report configured bot-field references followed by traffic review. Security-event counts are not unique requests, and the checks can overlap; never add their totals. High bot scores do not prove legitimate requests, and low scores do not prove attacks. Sampled or partial observations remain visible but do not justify enforcement changes. API coverage is limited to endpoints matched in the connected service’s inventory. Field references do not prove requests matched, effective enforcement, or savings. Disabled rules are excluded; application code and built-in protections are outside this inventory. Older scans retain their historical observations.

Scan notifications

Each workspace member gets an in-app notice for future completed or partial scans. Owners may opt in under Notification preferences to email their own signed-in address; email starts off. Notices link to the scan's evidence and coverage, not a promise of findings. Email contains no findings or credentials. Opt-out cancels pending mail but cannot recall an in-flight message; delivery retries may occasionally duplicate a notice. Provider acceptance does not prove inbox delivery. Notifications and preferences are included in owner exports and removed with workspace deletion.

Weekly value reports

Workspace reports cover seven complete UTC days, from Monday 00:00 to the following Monday (end exclusive), and appear after that boundary. They preserve period findings, confidence changes against earlier assessments, coverage gaps, work-status changes, and results you report. The first report identifies workspace creation; days before it existed do not imply coverage. Reports are historical, not a current assessment or an automatic proof of savings. Amounts retain their own currencies and measurement windows and are not totaled. Owners may separately opt in to report emails; scan email consent does not enable them. Email is off by default and contains only a protected link. Only signed-in workspace members can follow report/source links. Owners can export report records; workspace deletion removes them. Generation and delivery may be delayed, and retries can duplicate email.

Empty or partial assessments

No findings means no eligible finding was detected in the covered scope and window. It is not a guarantee that an environment is fully optimized. Permission errors, unavailable datasets, and insufficient traffic should be resolved or acknowledged before drawing broader conclusions.

Older records

Use the Load more controls for older findings, scans, checks, reviews, and results. Each page is bounded, but the lists have no total record cap. If the workspace changes while you browse, refresh the affected list before continuing. Expanded scan and finding lists remain in place during automatic polling; refresh them to see new changes.

Rescans, schedules, and workspace deletion

Start a new manual scan after changes and inspect its coverage. Owners can also enable daily or weekly rescans on an active connection; the scheduler skips a run when the interval has not elapsed, a scan is already in progress, or selected zones are not ready. A new assessment shows whether a finding persists, changes, is no longer detected, or cannot be assessed. Missing evidence and failed scans never establish resolution. Your work status, dismissals, feedback, and measured results stay separate and are not overwritten. Completed assessment history remains available, and past recommendations are labeled historical. Token rotation requires selecting zones again. Disconnect erases the stored token and cancels active scans; also revoke the token in your infrastructure account. Owners can delete the workspace after confirmation, which cancels in-flight scans, wipes stored credentials, and removes the workspace records.

Explore the sample assessment