Maestro's Open GitHub Issues: 47 Flakiness

Maestro promises “built-in flakiness handling.” But a look at their GitHub issues tells a different story. Here are 15 open issues—some dating back over 2 years—that reveal the gaps in Maestro’s reliability.

Timeout Issues: “It Just Ignores My Settings”

#2843 - waitForAnimationToEnd does not respect timeout

Status: Open

The Problem:

- waitForAnimationToEnd:
    timeout: 2000

User sets 2-second timeout. Maestro waits 6+ seconds anyway.

From the issue:

“Animation doesn’t timeout within 2000, if you check the logs it carries on the animation until it finishes after around 6 seconds”

The logs prove it:

13:56:49.675 [ INFO] Waiting for animation to end with timeout 2000
... (6 seconds later)
13:56:55.xxx [ INFO] Wait for animation to end COMPLETED

Link: github.com/mobile-dev-inc/maestro/issues/2843

#2734 - waitForAnimationToEnd doesn’t accept JS parameter

Status: Open

Can’t even use JavaScript to set the timeout dynamically. The parameter is simply ignored.

Link: github.com/mobile-dev-inc/maestro/issues/2734

#2864 - Allow evaluation of JS expressions in timeout

Status: Open

Feature request to allow:

- waitForAnimationToEnd:
    timeout: ${CUSTOM_TIMEOUT}

Still not possible.

Link: github.com/mobile-dev-inc/maestro/issues/2864

Flaky Assertions: “It’s Right There on Screen!”

#2298 - assertVisible randomly FAILED on displayed text

Status: Open

The Problem: Text is clearly visible in the screenshot, but Maestro says it’s not there.

From the issue:

“75% of the time the test runs correctly on this screen, and 25% of the time it fails, even though we’re in exactly the same configuration.”

The screenshot attached to the issue clearly shows the text. Maestro just… doesn’t see it.

Environment: Flutter app, Android 15 emulator.

Link: github.com/mobile-dev-inc/maestro/issues/2298

#2236 - Elements not found on initial load

Status: Open

The Problem: TestIDs and elements aren’t visible to Maestro when the app first loads, even though they’re rendered.

From the issue:

“Currently testID and React Native elements are not visible during the initial load of the application”

Includes video proof showing the element is there, but Maestro can’t find it.

Environment: Expo/React Native, iOS 17.

Link: github.com/mobile-dev-inc/maestro/issues/2236

Tap Failures: “It Says It Tapped, But Nothing Happened”

#2448 - tapOn succeeds but navigation doesn’t trigger

Status: Open

The Problem: Maestro reports the tap succeeded. The UI doesn’t change. Manual taps work fine.

From the issue:

“When using Maestro CLI, calling tapOn on a bottom tab bar button succeeds mechanically (Maestro confirms the tap), but does not trigger actual tab navigation. However, tapping manually and tapping through Maestro Studio work correctly.”

The same tap works in Studio but fails in CLI. That’s a tooling bug, not app flakiness.

Link: github.com/mobile-dev-inc/maestro/issues/2448

#2326 - Mismatch between screenshotBasedTap and hierarchyBasedTap

Status: Open

The Problem: The code has the tap methods assigned to the wrong platforms.

From the PR:

“Assign tap-based function with its correct implementation. Previous PR reference: #787”

iOS was using hierarchy-based taps, Android was using screenshot-based. They were swapped.

Link: github.com/mobile-dev-inc/maestro/issues/2326

#2062 - tapOn placeholder doesn’t always work

Status: Open

The Problem: Tapping on input fields by placeholder text works intermittently.

Environment: React Native, iOS.

Link: github.com/mobile-dev-inc/maestro/issues/2062

Input Flakiness: “It Types… Most of the Characters”

#2382 - inputText flakily skips numbers on iOS

Status: Open

The Problem:

- inputText: '4049389283'

Result: 409389283 (dropped the second 4)

- inputText: '2025'

Result: 2050 (dropped the 2, kept extra 0?)

From the issue:

“Breaking the string up into no more than two numbers per inputText works.”

Workaround: Type two characters at a time. That’s not “built-in flakiness handling.”

Environment: Expo, iOS 17, M1 Mac.

Link: github.com/mobile-dev-inc/maestro/issues/2382

CI Flakiness: “Works Locally, Fails in CI”

#2610 - Deep links “extremely flaky” on GitHub Actions

Status: Open

The Problem: Opening deep links fails randomly in CI but works locally.

From the issue:

“Opening deep links on iOS simulator extremely flaky on GitHub Actions”

The user created a full reproduction repository with CI artifacts proving the flakiness across multiple Maestro versions (1.39.0 through 1.41.0).

Link: github.com/mobile-dev-inc/maestro/issues/2610

#2497 - No retry on “Operation timed out”

Status: Open

The Problem: When CI is slow and a deep link times out, Maestro doesn’t retry. The test just fails.

From the issue:

“When opening a deep link to the app that still didn’t finish fully loading (e.g. because CI is slow), it may sometimes/often fail with: Operation timed out”

No built-in retry for this common CI scenario.

Link: github.com/mobile-dev-inc/maestro/issues/2497

Feature Requests: Open for Years

#423 - Configurable tolerance timeout (Open since 2022)

Status: Open for 2+ years

The Request:

appId: com.company.app
timeout: 10000  # Global timeout
---
- assertVisible: Button

From the issue:

“I’m running maestro tests on an emulator in CI on a very slow machine. It’s so slow, that it takes approximately 4 seconds to type a single letter… I know that we have extendedWaitUntil, but it’s not suitable to replace everywhere.”

Link: github.com/mobile-dev-inc/maestro/issues/423

#684 - Custom timeout for conditional flows (Open since 2023)

Status: Open for 2+ years

The Request:

- runFlow:
    when:
      visible: Some Text
      timeout: 30000  # Custom timeout for this condition
    file: subflow.yaml

Currently, conditions use a hardcoded 7-second timeout for optional elements. You can’t change it.

Link: github.com/mobile-dev-inc/maestro/issues/684

#1252 - Specify test timeout duration (Open since 2023)

Status: Open for 1.5+ years

The Problem: Tests can hang indefinitely. No way to set a maximum test duration.

From the issue:

“There seems to be some edge cases where tests go into infinite waits for a script to run/complete. In these scenarios the test will never complete.”

Link: github.com/mobile-dev-inc/maestro/issues/1252

#2801 - Add timeout property for conditions (Open PR)

Status: PR exists, not merged

A community member actually submitted a PR to fix #684:

- runFlow:
    when:
      visible: 'Login'
      timeout: 500  # Short timeout since app should be settled
    commands:
      - tapOn: 'Login'

The PR exists. It’s been open. Still not merged.

Link: github.com/mobile-dev-inc/maestro/pull/2801

The Pattern

The bugs are recent. The feature requests are ancient. For CI/CD setup despite these issues, see Maestro CI/CD: GitHub Actions & Jenkins.

The Takeaway

These aren’t edge cases. They’re:

• Text visible on screen but assertion fails
• Tap reported as success but nothing happens
• Timeout explicitly set but ignored
• Basic configurability requested for 2+ years

“Built-in flakiness handling” that creates its own flakiness isn’t handling—it’s hiding. When you consider the real cost of flaky tests, these unresolved issues represent real money lost. For a full framework comparison, see Maestro vs Appium 2025.

Want to Help?

These issues are open. If you’ve experienced them:

1. Add your reproduction steps
2. Upvote with a thumbs up
3. Submit PRs (like #2801)

The Maestro team is small. Community contributions matter.

We’re Not Just Documenting Problems

We love Maestro’s YAML syntax. It’s why we’re investing in the ecosystem.

But we’re also building something to address these gaps: an open-source engine that runs Maestro YAML on Appium’s battle-tested infrastructure. Configurable timeouts. Real retry logic. No ignored parameters.

Watch this space.