State Licensing Source Interruptions: What Mesh Observed in One Year

 Mesh logged 102 outages and maintenance windows affecting 54 licensing sources across 40 states between September 15, 2025 and September 15, 2026.  

What Mesh Observed

Between September 15, 2025 and September 15, 2026, Mesh’s operations team logged 102 license-verification interruptions affecting 54 licensing sources across 40 states. These included 75 unplanned outages and 27 announced maintenance windows—roughly two logged interruptions per week during the study period.

Each interruption represents a deduplicated event involving a licensing lookup or data source, not an individual failed license check. The log includes only interruptions encountered by Mesh’s operations team during license-verification work.

These findings do not represent a nationwide licensing-board uptime rate or the probability that an individual verification will fail. An unavailable licensing source does not establish that a vendor is unlicensed.

Study scope

• Observation period: September 15, 2025 through September 15, 2026.

• Source: Internal reports created by Mesh’s operations team during license-verification work.

• Unit counted: A deduplicated interruption involving a licensing lookup or data source—not an individual failed license check.

• Included: Unplanned outages and announced maintenance windows encountered during verification work.

• Excluded: Five cases in which bot protection blocked automated access while the source remained available to a person.

• Limitation: The log does not measure nationwide uptime, calculate a per-source failure rate, or capture interruptions Mesh did not encounter.

How many licensing-source interruptions did Mesh log?

Mesh logged 102 licensing-source interruptions during the observation period: 75 unplanned outages and 27 announced maintenance windows. The monthly totals show when Mesh encountered these interruptions, but they are not adjusted for verification volume and should not be interpreted as monthly failure rates or evidence that licensing sources became less reliable.

Logged licensing-source interruptions by month, September 15, 2025–September 15, 2026

*September 2025 and September 2026 are partial months. The observation period runs from September 15, 2025 through September 15, 2026.

How long did the observed interruptions last?

Duration information was available for 40 of the 102 logged interruptions. Of those 40, 13 were observed to clear the same day and 12 took two to seven days. The remaining 15 known-duration incidents lasted longer, but the current research summary requires clarification before they can be divided accurately into week-long and months-long categories. Duration was not established for the other 62 interruptions.

A contractor registry remained unavailable online for about seven months

In August 2025, one state’s home improvement contractor registry went offline along with the rest of its agency’s systems. Consumers had no way to confirm a contractor’s registration. According to the agency’s public updates, a phone helpline for status checks opened in November, and the searchable lookup came back in March 2026. That was about seven months after it went down.

The interruption created different workflow choices at different stages. Before the phone helpline became available, a platform could hold the verification or consult previously retrieved data while clearly disclosing its retrieval date and limitations. After the helpline opened, a manual status check became another possible fallback. In every case, the unavailable online lookup needed to remain distinct from a “not found” result. Holding a verification or using an alternative source does not authorize approving an unverified vendor; escalation and fallback decisions must follow the platform’s compliance policy.

What repeat interruptions mean for license verification workflows

Mesh’s operations log shows that licensing-source interruptions were concentrated among a subset of sources and sometimes occurred close together. These patterns can help platforms identify where stronger retry, fallback, and exception-handling processes may be needed. They do not establish a source’s overall failure rate or the frequency of incorrect verification results.

Repeat interruptions were concentrated. Twenty-one licensing sources experienced more than one logged interruption and accounted for 69 of the 102 incidents. The other 33 sources appeared once in the log. Repeat incidents identify sources that may require stronger exception handling, but the study did not measure how often those interruptions produced false “not found” results.

Interruptions also clustered in time. The busiest weekly reporting period contained eight logged incidents. Without corresponding verification-volume data, that count does not establish that the sources became less reliable or quantify the effect on review queues and support demand.

Automated-access blocks were treated separately. Mesh excluded five cases in which bot protection prevented automated access while the licensing source remained available to a person. These cases were not counted among the 102 interruptions, but they represent a different operational condition: an automated verification may be unable to proceed even when a manual lookup remains possible.

What should a platform do when a licensing source is unavailable?

When a licensing source is unavailable, the platform should preserve that uncertainty rather than converting it into a “not found” result. Retry schedules, fallback evidence, escalation, and vendor decisions should follow the platform’s compliance policy. Holding a verification does not authorize approving an unverified vendor.'

• Return “source unavailable” as a distinct outcome. A timeout, error page, or inaccessible lookup does not establish whether the license exists. Keep source availability separate from license status.

• Retry according to a defined policy. Among the 40 interruptions with known duration, 25 were observed to clear within seven days. Retrying after a source recovers may allow the verification to continue, but it does not guarantee that every check will resolve automatically or without review.

• Identify the age and source of fallback data. If the workflow consults a previously retrieved record, display its retrieval date and provenance. The platform’s policy should determine whether that evidence remains usable or requires additional review.

• Explain the delay accurately. Tell the vendor that the licensing source is unavailable and that the verification will be retried or reviewed. Do not communicate source unavailability as evidence that the license was not found.

• Track interruptions by source. Record the affected source, incident type, observed start and recovery times, retry outcomes, and any fallback method used. Over time, that history can identify sources that require stronger contingency planning.

Methodology and limitations

Mesh reviewed internal operations reports created between September 15, 2025 and September 15, 2026 that described a licensing lookup or data source as unavailable or under maintenance. The review identified 139 reports. Multiple reports concerning the same source within ten days—including updates such as “still down” or “back up”—were consolidated into one incident. Incidents affecting different sources were counted separately, even when the sources were located in the same state. After consolidation, the study contained 102 logged interruptions.

The 102 interruptions include 75 unplanned outages and 27 announced maintenance windows. Five cases in which bot protection blocked automated access while the source remained available to a person were excluded. Licensing-source and state names are withheld from the published report.

The log includes only interruptions Mesh encountered during license-verification work. It does not capture interruptions that occurred when Mesh was not accessing the affected source. Therefore, the study cannot establish a nationwide uptime rate, a per-source failure rate, or the probability that an individual verification will fail. Additional interruptions may have occurred outside the team’s observation, so the log should not be treated as exhaustive.