A rejection reason is more useful than a total
Rejected work may be labeled stale, invalid, duplicate, unauthorized, or another provider-specific category. These labels do not all point to the same cause. A sustained pattern deserves investigation, while a single event rarely establishes a hardware diagnosis.
Collect timestamps and compare device logs with the pool’s definitions. Timing and connectivity can affect submissions, while incorrect configuration or device errors can produce different patterns. Avoid risky overclocking or firmware changes as an unstructured first response.
Step-by-step
- Classify the events. Record counts or difficulty-weighted work, rejection reasons, observation window, assigned difficulty, and whether multiple miners are affected.
- Check the common path. Verify supported endpoint, credentials, protocol, network reachability, and service status. Compare timestamps before attributing a fleet-wide event to individual boards.
- Change one variable. Use supported settings and preserve a baseline. If device-specific errors persist, follow the manufacturer’s safe troubleshooting process or contact support with sanitized logs.
Worked example
Illustrative example. Two hypothetical workers lose accepted submissions at the same minute after a network interruption. Investigating their shared connection is more informative than immediately replacing both machines’ components.
Correlation is a clue, not proof. Confirm the rejection reason and service evidence before assigning a cause or buying replacement parts.
Common mistakes
- Comparing raw rejection counts across different share difficulties.
- Increasing clock settings to fix an unexplained invalid-share pattern.
- Including account secrets in public troubleshooting logs.
Questions and answers
Is there a universal acceptable rejection percentage?
No. Definitions, workload, and measurement methods vary. Use provider guidance, compare your own stable baseline, and investigate meaningful changes with reason-specific evidence.
Apply this to your setup
Create an incident log with reason category, difficulty-weighted amount if available, interval, affected workers, and relevant device or network events. Make one supported change at a time and compare equivalent periods. Escalate with sanitized evidence if the cause remains unexplained; a declining raw count after a difficulty change is not a verified repair.
Sources and next steps
Read share difficulty and monitoring baselines.
How this guide was prepared: AI-generated drafting with the linked technical references and illustrative calculations. It does not report first-hand equipment tests or a named specialist review.