Difference in Invalid Characters for Runbook Add vs. Update

Build: 2021.3.12132
We are needing to update versions, but I also didn’t see this in any of the release notes of the more recent releases.

To reproduce this, add a Runbook (Manual Intervention was what I happened to do) and name it something like “Test: Octopus Runbook Characters”, add in data for the other required fields, and hit “Save”.

Then go to “Update” and add a 1 anywhere to the runbook name so you can save. You will get the following error

'Test: Octopus Runbook Characters1' contains invalid characters. Names can only contain letters, numbers, periods, commas, dashes, underscores or hashes.

and the list of special characters does not include colons.

Hi @mpeterson,

Thanks for posting your question!

It doesn’t look like I’m able to reproduce the behavior you’re reporting in 2021.3.12132, so I was wondering if you could provide a few screenshots and the exact steps you’re following to get the error to show?

If you’re ok with it, would you be willing to capture a HAR file and send it securely to me using the following link? mpeterson - Octopus Support

This will give me an idea of where Octopus is encountering this validation so I can further investigate on my end.

Looking forward to hearing back from you.


Hi Patrick,

Let’s start with a more detailed walkthrough of what I’m seeing. If that doesn’t help you reproduce, I’ll get you a HAR file, but I can’t think of anything we have done to customize Octopus, and this doesn’t feel like a customization thing. The thing that comes to mind specifically is you may have thought adding a process step to a runbook. I did reference manual intervention and although that was what I was doing for the runbook where I hit this, I shouldn’t have included it because it doesn’t matter for the issue I’m mentioning. This is specifically on the Runbook itself.


Hey @mpeterson,

Thanks for the detailed reproduction steps, that always really helps us out. I tested your steps on our Cloud instance, version 2022.3.2617-hotfix.4278, and could not reproduce. However, I also tried those steps on my local server version of 2022.1.2386 and wasn’t able to save during the first step of creating the runbook with the title ‘Test: Octopus Runbook’ as it threw that same error:

I believe your issue may be with the colon. I’m not sure why you can use the colon initially in your version, but it’s blocked in my local version, which was released later. Could you try the same steps but without the colon? I’m curious what will result. Also, no matter the outcome, it appears that our later Octopus versions 2022.3 properly allow those characters to be used in the runbook name, so once upgraded, this issue won’t occur.

I am looking forward to hearing back from you.


Hi Brent / Patrick,

It is definitely because of the colon. This was more about logging an inconsistency (which I didn’t see a mention of being fixed in later revisions).

The specific version I have is

2021.3.12132 as noted below.

Hey @mpeterson,

Thanks for getting back to us and for the clarification.

It looks like we’ve fixed this inconsistency in later versions of Octopus (e.g. 2022.2.6872), as I’ve tested it and the validation shows immediately upon trying to create the Runbook rather than on the “update” to the name.

I found a GitHub issue where where we’ve addressed this, and you can see which versions it’s been fixed in towards the bottom of the issue: Runbook names validation is not consistent in UI and in export/import · Issue #7381 · OctopusDeploy/Issues · GitHub

I understand you’re not really concerned about being able to use special characters in the Runbook name at this point, but I wanted to mention that you will likely still have a problem with the colon and other characters in later versions of Octopus. This is due to the Runbook name validation being tied to the OS filesystem filename validation, so it’s limited to what Windows will support there. I’m following up internally to better understand why this validation is designed in this manner, and I’ll let you know what I find.


Hi Patrick,

Just to clarify what you wrote, I can see where I’d also have issues editing these going forward if we happened to want to change the name. That we can deal with and fix. However another scenario occurred to me as I was reading your response. Is there a case where we might have issues executing these if we snuck them with invalid characters and try to execute them?


Hi Mike,

That’s a great question, and I can answer that and clarify my earlier response.

It doesn’t look like this should impact the ability to run improperly named runbooks in alter versions of Octopus, though you’re right you would hit the validation issue if you attempted to rename the runbook. However, as long as you pick a valid name for the Runbook when you update it, it will save.

Also, you might encounter the issue reported in the #7381 issue where if you attempt to export/import the runbook into another instance it would fail validation on import.

I tested this by following your repro steps in 2021.3.12132 but didn’t rename the runbook (so I kept its name as Test: Octopus Runbook) and made sure it would run. I then upgraded my Octopus instance to 2022.2.6872 and attempted to re-run the Runbook, and it was successful. I could also rename it with a valid name.

Hopefully that answers your questions, but let me know if you need anything else.


This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.