Ultimately we don't want to use the form-builder approach for our fleet integration. We should build a minimal version of the HTTP UI (just the standard form builder fields we already have) using custom components, as the endpoint security app does today as a next milestone.

We don't need for elastic/uptime#235 to be fully complete since we're blocked on some heartbeat stuff, but we can move forward here.

The team have identified these as simpler configurations to add in the custom UI:

• Name
• Service.name
• Schedule
• Timeout
• Tags
• Hosts
• Max_redirects
• Proxy_url
• Headers
• Check (Lots of options here, shouldn't be too bad, but could use a pass from design)

These are more complex and may need some @elastic/observability-design input:

• Ipv4 (goes in advanced tab? Seldom set option)
• Ipv6 (goes in advanced tab? Seldom set option)
• Mode (goes in advanced tab? Seldom set option)
• Fields (goes in advanced tab? Seldom set option)
• Processors (do we even allow this elsewhere in fleet? I think we could omit this for quite some time OR make it an expert thing where you write YAML, a UI here would be quite complex)
• SSL (this should be standard across a number of integrations, is there a shared widget?)
• Username / Password ( we need to sync with the fleet team on handling secrets)

We also need to finalise the name for the integration (for this HTTP Ping monitor type) @drewpost

Progress

Fields

Mappings

• [ x Ensure mappings are correct

Fleet Custom UI

• Ensure create view works appropriately
• Ensure edit view works appropriately

Uptime UI

• Ensure that monitors appear in uptime monitor list alongside the heartbeat* index

Documentation

• Assess where to include common documentation (Decided to add inline documentation that essentially duplicates heartbeat documentation for now
• Assess where to include monitor type specific documentation (Inline)

Tests

• Write unit tests

Accessibility Notes

• The fleet form doesn't appear to follow the EUI form validation guidelines.
• The fleet page doesn't appear to be wrapped in <form>
• Think through how to express fields, such as headers, that are currently disabled
• Think through how to associate the key field with the value field in the headers component

Responsiveness notes

• The fleet submit button appears to overlay the form fields in mobile

Content

• Settle on field names
• Settle on any field helper text
• Settle on content for left hand side form descriptions

Data notes

• Check that default values in the UI represent default values for inline monitors. Compare against documentation

Testing notes

• How do I verify that headers are being applied appropriately?

Questions

• Should we add location? (No, long term cross team project)
• Should we include a Port input for tcp monitors, since the Host input already includes support for a port? (Decided to exclude port and add help text)
• How do we include formatting for body?

Design questions

• Consider include a dropdown for the units of time for monitor schedule, i.e. seconds vs minutes

Product notes

• How do we handle documenting how each field impacts the monitor and the appropriate values? Should we point the user to current heartbeat documentation? Write new documentation? Document everything inline online using field helper text?