Skip to content

feat: add TLS Cert Expiry alert for TCP checks #1153

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Jun 13, 2025

Conversation

VikaCep
Copy link
Contributor

@VikaCep VikaCep commented May 23, 2025

Closes #1149
Depends on https://github.com/grafana/synthetic-monitoring-api/pull/1357

Add "TLS Certificate Close to Expiring" Alert for TCP Checks

Summary

This PR introduces support for the "TLS certificate close to expiring" alert for TCP checks in the synthetic monitoring app.

Details

  • Feature:

    • Users can now enable a per-check alert for when the target’s TLS certificate is close to expiring on TCP checks.
  • UI/UX:

    • The alert option is only available if TLS is enabled in the TCP check’s "TLS Config" section.
    • If TLS is not enabled, the alert checkbox is disabled and a warning message is displayed to inform the user that TLS must be enabled for this alert to function.
      image
  • Tests:

    • Added tests to verify:
      • The alert can be enabled and submitted when TLS is enabled.
      • The alert is disabled and a warning is shown when TLS is not enabled.
Screen.Recording.2025-05-23.at.14.50.09.mov
@VikaCep VikaCep self-assigned this May 23, 2025
@VikaCep VikaCep marked this pull request as ready for review June 4, 2025 20:45
@VikaCep VikaCep requested a review from a team as a code owner June 4, 2025 20:45
@VikaCep VikaCep requested a review from w1kman June 4, 2025 20:45
@VikaCep
Copy link
Contributor Author

VikaCep commented Jun 4, 2025

Since https://github.com/grafana/synthetic-monitoring-api/pull/1357 has been merged I've marked this as ready for review. However, I don't know if we want to include it in the public preview. Do we need to update the docs for it @ka3de?

@ka3de
Copy link
Contributor

ka3de commented Jun 5, 2025

However, I don't know if we want to include it in the public preview. Do we need to update the docs for it @ka3de?

I would say this is not a must, but whenever it's ready we can merge it. Docs are updated in this PR which is ready to merge when the functionality is released.

@VikaCep VikaCep requested a review from ckbedwell June 9, 2025 18:56
w1kman
w1kman previously approved these changes Jun 11, 2025
Copy link
Contributor

@w1kman w1kman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - I'm not sure about the orange/warning color for the text.
Seems a bit much. Perhaps double check with @vesnadean ?

describe(`TCPCheck - Section 4 (Alerting) payload`, () => {
it(`can add TLS certificate expiry alert when TLS is enabled`, async () => {
jest.replaceProperty(config, 'featureToggles', {
// @ts-expect-error
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've removed the error suppressions here and created a utility function to override feature flags in tests 👍

VikaCep added 2 commits June 11, 2025 14:58
- also removes the need for TypeScript error suppression comments related to feature flag overrides
@vesnadean
Copy link

LGTM - I'm not sure about the orange/warning color for the text. Seems a bit much. Perhaps double check with @vesnadean ?

I see a couple options here:

  1. If this checkbox is selected, we check whether TLS is enabled or not. If not, the alert won't work properly. In this case we display an error warning in red. I assume we don't have that logic in place atm?
  2. We don't check if TLS is enabled or not, and this text is just for additional clarification. In this case we use the secondary text color.
@VikaCep
Copy link
Contributor Author

VikaCep commented Jun 12, 2025

Thanks @vesnadean! I took another look, and since we don’t want to allow saving the alert when TLS is off, I went ahead and added a validation rule to handle that case, to be consistent with other invalid scenarios:

Recording:
https://github.com/user-attachments/assets/2806aa6e-8ab3-4945-9659-3e8f364c4f44

image

This should help in cases where someone creates a check with the alert enabled and then later disables TLS by preventing that mismatch from being saved.

If we’d rather not go with validation, we could fall back to just showing the message in a secondary color like you suggested:

image

Let me know which alternative you think is best 🙏

@VikaCep VikaCep requested a review from w1kman June 12, 2025 19:34
@vesnadean
Copy link

@VikaCep The recording looks great, let's go with that option.

Copy link
Contributor

@w1kman w1kman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! 👍🏻

@VikaCep VikaCep requested a review from w1kman June 13, 2025 13:23
@VikaCep VikaCep merged commit 7fe153a into main Jun 13, 2025
13 of 14 checks passed
@VikaCep VikaCep deleted the feat/support-tls-alert-for-TCP-checks branch June 13, 2025 13:30
@sm-release-app sm-release-app bot mentioned this pull request Jun 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
4 participants