Apply suggestions from code review

Co-authored-by: Michał Olender <[email protected]>

Author: patrikbraborec

sources/platform/actors/development/programming_interface/status_messages.md

@@ -77,14 +77,14 @@ async def main():
 </TabItem>
 </Tabs>
 
-## Communicating limitations
+## Communicate limitations
 
-If your Actor has specific limitations for users on the Apify free plan (e.g., restricted features, limited results), it is crucial to communicate these clearly to avoid confusion.
+If your Actor has specific limitations for users on the Apify free plan (e.g., restricted features, limited results), communicate these clearly to avoid confusion.
 
 - Status messages: Use `Actor.setStatusMessage` or `Actor.exit` message to explain why a run finished early or failed (e.g., "Daily limit for free plan reached. Upgrade to continue.").
-- Avoid false errors: Do not return generic system errors or fail the run in a way that looks like a platform issue. This frustrates users and makes troubleshooting difficult.
+- Provide clear error messages: Don't return generic system errors or fail the run in a way that looks like a platform issue. This frustrates users and makes troubleshooting difficult.
      - Wrong: API usage is limited to 10 results
      - Right: This Actor only allows up to 10 results for free users. Upgrade to a paid plan to receive unlimited results.
 - Documentation: Clearly state any limitations in your Actor's `README` and input schema descriptions so users know what to expect before running the Actor.
     - General restrictions (like limiting the number of results) must be explained in the top-level input schema description that renders above the input editor UI.
-    - Feature-specific limitations must be included in the title of an input field. The title must include explanation in parenthesis such as `(paying users only)` or `(limited for free users`). E.g. `Max comments (paying users only)`.
+    - Feature-specific limitations must be included in the title of an input field. The title must include explanation in parenthesis such as `(paying users only)` or `(limited for free users)`. E.g. `Max comments (paying users only)`.

sources/platform/actors/publishing/monetize/index.mdx

@@ -100,12 +100,12 @@ If no action is taken, the payout will be automatically approved on the 14th, wi
 
 If the monthly profit does not meet these thresholds, as per our [Terms & Conditions](https://apify.com/store-terms-and-conditions), the funds will roll over to the next month until the threshold is reached.
 
-## Handling free users
+## Handle free users
 
-When monetizing your Actor, you might want to limit features or usage for users on the Apify free plan. If you choose to do this, you **must** handle it transparently:
+When monetizing your Actor, you might want to limit features or usage for users on the Apify free plan. If you choose to do this, you _must_ handle it transparently:
 
 - Communicate upfront: Clearly state any limitations in your Actor's `README` and input schema. Users should know about restrictions _before_ they run the Actor.
-- Graceful exits: If a free user hits a limit, do not crash the Actor or return a system error. Instead, exit gracefully with a clear [status message](/platform/actors/development/programming-interface/status-messages#communicating-limitations) explaining the limit (e.g., "Free tier limit reached").
+- Graceful exits: If a free user hits a limit, don't crash the Actor or return a system error. Instead, exit gracefully with a clear [status message](/platform/actors/development/programming-interface/status-messages#communicating-limitations) explaining the limit (e.g., "Free tier limit reached").
 - Avoid confusion: Never make a policy restriction look like a bug or platform error.
 
 ## Actor analytics