Neto by Maropost Incident History

On Jul 24, 2026, some customers experienced intermittent slowness across parts of the service during two short periods. Our team identified elevated traffic and processing load as the cause, took action to reduce the load, and restored stable performance. The issue is now resolved and we are continuing to monitor closely. We are taking steps to improve resilience and help prevent similar issues from recurring.

This incident has been resolved.

Our team has deployed a fix and is closely monitoring the situation to ensure services return to normal.

We are currently investigating reports of intermittent slowness affecting the Neto Control Panel.

On **July 23, 2026**, customers experienced intermittent slowness while accessing the **Neto Control Panel**, impacting approximately **20% of requests**. The issue was caused by an infrastructure configuration change that introduced a mix of instance types with different performance characteristics, resulting in some instances becoming overloaded under production traffic. Our engineering team resolved the issue by removing the affected instance type, replacing the impacted instances with compute-optimized instances, and updating the infrastructure configuration to prevent recurrence. We are also implementing additional improvements to our load-balancing configuration and infrastructure validation processes to further enhance platform reliability.

This incident has been resolved.

A fix has been implemented and we are monitoring the results.

The issue has been identified and a fix is being implemented.

We are currently investigating reports of intermittent slowness affecting the Neto Control Panel. Users may experience delays while accessing or navigating the Control Panel. Our Engineering teams are actively investigating the issue to identify the root cause and restore normal performance as quickly as possible.

On 27 July 2026, a subset of merchants experienced an issue accessing their control panels. Affected users were shown a “We will be back online shortly” message after attempting to log in. The incident began at **11:48 AM AEST** and was resolved at **1:17 PM AEST**, for a total duration of **1 hour and 29 minutes**. ## What happened During a production software release, a change affecting a security-related control panel configuration caused authenticated requests to fail for a subset of control panels. The issue only affected control panels where the relevant security feature was enabled. Users could reach the login page, but after authentication they were unable to access the control panel. ## Impact Some merchants were temporarily unable to access their control panels and complete administrative tasks. The disruption was limited to a subset of control panels. Services returned to normal once the affected configuration was disabled. ## Timeline * **11:48 AM AEST** – Reports were received of control panels displaying “We will be back online shortly,” and the Development Team began investigating. * **12:35 PM AEST** – The cause of the issue was identified and remediation work began. * **12:55 PM AEST** – A fix was deployed and the service was placed under monitoring. * **1:17 PM AEST** – The issue was confirmed as resolved and services were operating normally. ## Root cause A change included in the production release caused an incorrect security reporting configuration to be generated for affected control panels. This produced a response header that exceeded the supported size limit, causing authenticated control panel requests to fail. ## Resolution The affected security feature was disabled, immediately restoring access to impacted control panels. A permanent code correction is also being implemented so the feature can operate without generating the invalid configuration. ## Preventive actions To reduce the likelihood of a similar incident, we are: * Adding regression coverage for authenticated control panel access when security-reporting features are enabled. * Expanding staging validation for response-header size and security configuration changes. * Improving release checks for feature-toggle combinations before production deployment. * Implementing the permanent code correction and validating it before re-enabling the affected feature. We apologise for the disruption and appreciate the patience of affected merchants while our teams worked to restore access.

The issue has been resolved and services are operating as normal.

Our team has deployed a fix and is closely monitoring the situation to ensure services return to normal.

We have identified the issue and our Development Team is working to resolve it as soon as possible.

We are receiving reports of control panels receiving "We will be back online shortly". Our Development Team are investigating now.

### Summary On 22 July 2026, merchants using the eBay integration experienced listing updates being skipped with the following error: > “Listing Duration is required. Record Skipped.” The incident was reported at 9:42 AM AEST and resolved at 4:40 PM AEST, with a total duration of approximately 6 hours and 58 minutes. We apologise for the disruption caused to merchants using the eBay integration. ### Impact During the incident, affected eBay listing records could not be processed successfully. This may have prevented merchants from creating or updating listings through the integration. Merchants who saved an eBay listing rule template while the issue was present may also have had some template fields saved without their expected values, despite the correct value continuing to appear in the interface. Other platform services were not affected. ### Root cause An internal data import process used to update shared eBay information was cancelled before it had completed. Because the process had already updated part of the dataset, its cancellation left required eBay information incomplete. This caused subsequent listing updates to fail validation and be skipped. A direct backup and restoration process for the affected shared database was not available. Our Development Team therefore used a point-in-time database recovery process to retrieve and restore the affected information. ### Resolution Our Development Team restored a production database to a separate recovery environment and extracted the affected tables. The recovered information was then restored across each of the relevant production database clusters. The first restoration was validated by Development and Support before the remaining clusters were updated. After the restoration was completed, we monitored the integration to confirm that eBay listing records were processing successfully before marking the incident as resolved. ### Merchant follow-up Merchants who saved an eBay listing rule template while the incident was occurring should re-save the affected template. To identify whether a template was changed during the incident: 1. Log in to your control panel. 2. Open **Reports**. 3. Select the **Staff User Log** report. 4. Enter `ebaytmpl` in the **Page Type** field. 5. Enter `edit` in the **Process** field. 6. Review edits made during the incident window. 7. Note the affected template IDs shown in the **Notes** column. 8. Open and re-save each affected eBay template. The **Listing Duration** field may have been saved as blank even though the interface continued to display “GTC.” Merchants who do not use eBay Business Policies should also review the fields under the template’s **Returns** section, as these fields may need to be re-entered before the template is saved. ### Timeline All times are in AEST on 22 July 2026. * **9:42 AM** – Investigation commenced after reports of eBay listing records being skipped. * **11:24 AM** – Point-in-time database restoration commenced. * **11:37 AM** – The recovery database was successfully restored. * **11:50 AM** – The affected information was extracted and prepared for restoration. * **12:05 PM** – Restoration of the first production database cluster was completed. * **12:11 PM** – Development and Support confirmed that the first restoration was successful. * **12:17 PM** – Restoration commenced across the remaining database clusters. * **12:43 PM** – Restoration was completed across all remaining clusters. * **2:33 PM** – The fix was confirmed as implemented and monitoring commenced. * **4:40 PM** – Monitoring confirmed that the integration was operating successfully and the incident was resolved. ### Follow-up actions We are reviewing the following improvements: * Adding safeguards around the cancellation of data import processes so that partially completed updates cannot leave shared information in an incomplete state. * Improving validation and recovery procedures for shared eBay integration information. * Restoring a working shared-database backup process to provide a faster and more targeted recovery option. * Reviewing whether additional validation can prevent templates from being saved when required underlying values are missing.

This incident has been resolved.

A fix has been implemented and we are monitoring the results.

The issue has been identified and a fix is being implemented.

We are continuing to investigate this issue.

We are currently aware of an issue affecting eBay integration, with an error message appearing stating: "Listing Duration is required. Record Skipped.". Our Development Team is actively investigating the issue.

Incident resolved This incident has been resolved.

UPDATE from Australia Post Incident status: Monitoring A fix has been implemented and we are monitoring the results. https://status.developers.auspost.com.au/incidents/l1qmd679b34p

Australia Post has reported an API degradation impacting the performance of Label Printing APIs. For the latest updates, please refer to the Australia Post developer status page: https://status.developers.auspost.com.au/incidents/l1qmd679b34p Please note that we are currently experiencing degraded performance on Label Printing APIs Our teams are currently investigating and we will keep you informed as we work to resolve the issue. Australia Post apologise for any inconvenience caused.