Summary:
The Save Page Now API is returning error status codes and timeout responses, but the content is actually being successfully archived. This creates confusion for automated tools that rely on the API response to determine archival success.
Expected Behavior:
When the Save Page Now API successfully archives a URL, it should return a success status code and confirmation.
Actual Behavior:
The API returns error responses (523 errors, connection timeouts) but the URLs are successfully archived and appear in the Wayback Machine with the correct timestamp.
Evidence:
API returned: ✗ Failed to archive: https://apps.dtic.mil/sti/pdfs/ADA521311.pdf (Status: 523)
But URL was successfully archived: Shows "Saved 1 time September 23, 2025" in Wayback Machine
Similar pattern observed with timeout errors: HTTPSConnectionPool(host='web.archive.org', port=443): Read timed out. (read timeout=30)
Impact:
Automated archival tools incorrectly report failures
Success metrics are inaccurate
Users may attempt to re-submit already archived content
Makes it difficult to build reliable automated preservation workflows
Suggested Fix:
Return accurate status codes that reflect actual archival success/failure
Or provide a separate verification endpoint to check archival status after submission
Improve API documentation to clarify expected behavior for edge cases
Environment:
API Endpoint: Save Page Now API
Observed: September 2025
Frequency: Multiple instances across different URL types
This appears to be a backend issue where the archival process succeeds but the API response doesn't accurately reflect the success state.
Summary:
The Save Page Now API is returning error status codes and timeout responses, but the content is actually being successfully archived. This creates confusion for automated tools that rely on the API response to determine archival success.
Expected Behavior:
When the Save Page Now API successfully archives a URL, it should return a success status code and confirmation.
Actual Behavior:
The API returns error responses (523 errors, connection timeouts) but the URLs are successfully archived and appear in the Wayback Machine with the correct timestamp.
Evidence:
API returned: ✗ Failed to archive: https://apps.dtic.mil/sti/pdfs/ADA521311.pdf (Status: 523)
But URL was successfully archived: Shows "Saved 1 time September 23, 2025" in Wayback Machine
Similar pattern observed with timeout errors: HTTPSConnectionPool(host='web.archive.org', port=443): Read timed out. (read timeout=30)
Impact:
Automated archival tools incorrectly report failures
Success metrics are inaccurate
Users may attempt to re-submit already archived content
Makes it difficult to build reliable automated preservation workflows
Suggested Fix:
Return accurate status codes that reflect actual archival success/failure
Or provide a separate verification endpoint to check archival status after submission
Improve API documentation to clarify expected behavior for edge cases
Environment:
API Endpoint: Save Page Now API
Observed: September 2025
Frequency: Multiple instances across different URL types
This appears to be a backend issue where the archival process succeeds but the API response doesn't accurately reflect the success state.